The man-page crypt_checkpass.3 makes a reference to the constant
'_PASSWORD_LEN' which is defined in but doesn't say so.
Index: lib/libc/crypt/crypt_checkpass.3
===
RCS file: /cvs/src/lib/libc/crypt/crypt_checkpass.3,v
retrieving rev
Hi Rafael,
Rafael Sadowski wrote on Tue, Sep 28, 2021 at 08:22:06AM +0200:
> On Mon Sep 27, 2021 at 11:20:55PM -0600, Theo de Raadt wrote:
>> Oh, like how about you try compiling a kernel after your proposed diff?
>>
>> in userland -
>>size_t comes from sys/types.h
>>or a header file whi
On Mon Sep 27, 2021 at 11:20:55PM -0600, Theo de Raadt wrote:
> Oh, like how about you try compiling a kernel after your proposed diff?
>
> in userland -
>size_t comes from sys/types.h
>or a header file which pulls in sys/types.h, and there should be
>no further new iteration added
>
Oh, like how about you try compiling a kernel after your proposed diff?
in userland -
size_t comes from sys/types.h
or a header file which pulls in sys/types.h, and there should be
no further new iteration added
in kernel -
size_t comes from either sys/param.h or sys/types.h, dependi
device.h misses a definition of size_t
/usr/include/sys/device.h:128:2: error: unknown type name 'size_t'
Index: device.h
===
RCS file: /cvs/src/sys/sys/device.h,v
retrieving revision 1.55
diff -u -p -r1.55 device.h
--- device.h1
On Thu, Mar 18, 2021 at 04:46:08PM +0100, Theo Buehler wrote:
> The port number starts after the ':'.
Agreed. OK claudio@
> Index: http.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/http.c,v
> retrieving revision 1.7
> diff -u
The port number starts after the ':'.
Index: http.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/http.c,v
retrieving revision 1.7
diff -u -p -r1.7 http.c
--- http.c 18 Mar 2021 15:40:45 - 1.7
+++ http.c 18 Mar 2021
Hi tech@,
Remove duplicated commented out "dev/rasops/files.rasops" include.
Comments? OK?
Index: sys/arch/i386/conf/files.i386
===
RCS file: /cvs/src/sys/arch/i386/conf/files.i386,v
retrieving revision 1.233
diff -u -p -r1.233 file
Remove duplicate include in file.c.
- Matthew Martin
diff --git file.c file.c
index 6304a38c18f..f7a2f56cb64 100644
--- file.c
+++ file.c
@@ -34,7 +34,6 @@
#include
#include
#include
-#include
#include
#include
#include
On Sat, Mar 28, 2015 at 5:38 PM, Ted Unangst wrote:
> Renato Westphal wrote:
>> > +#include
>> > #include
>
>> "#include ",
>> "#include ",
>
>> If you include the stdlib header in the .y file you will end up with
>> two includes for the same header in the .c file.
>
> Looks lik
Renato Westphal wrote:
> > +#include
> > #include
> "#include ",
> "#include ",
> If you include the stdlib header in the .y file you will end up with
> two includes for the same header in the .c file.
Looks like we're already including string.h twice. Probably makes sense
to
On Sat, Mar 28, 2015 at 09:42:00AM -0300, Renato Westphal wrote:
> I don't think that this is necessary. Yacc includes a skeleton C code
> when generating a parser from a grammar specification file (.y) and
> the stdlib header is in there:
>
> char *banner[] =
> {
> "#include ",
>
2015-03-28 8:56 GMT-03:00 Fabian Raetz :
> Hi tech@,
>
> should the stdlib.h header be included in parse.y files when calloc(3)
> is used?
>
> Regards,
> Fabian
>
>
> From ce8307e0bc7541b88a9a9bf949f6585adef46bb6 Mon Sep 17 00:00:00 2001
> From: Fabian Raetz
> Date: Sat, 28 Mar 2015 12:44:32 +0100
Hi tech@,
should the stdlib.h header be included in parse.y files when calloc(3)
is used?
Regards,
Fabian
>From ce8307e0bc7541b88a9a9bf949f6585adef46bb6 Mon Sep 17 00:00:00 2001
From: Fabian Raetz
Date: Sat, 28 Mar 2015 12:44:32 +0100
Subject: [PATCH] include stdlib.h because of calloc(3) usag
On Wed, Nov 19, 2014 at 1:00 PM, Ted Unangst wrote:
> The sys/file.h include is likely not the correct include for any
> userland code. Most cases it's unneeded; in other cases fcntl.h is the
> correct header.
Yep. Diff looks good; ok guenther@
The sys/file.h include is likely not the correct include for any
userland code. Most cases it's unneeded; in other cases fcntl.h is the
correct header.
Index: bin/ed/buf.c
===
RCS file: /cvs/src/bin/ed/buf.c,v
retrieving revision 1.19
On Thu, Nov 13, 2014 at 10:31 PM, Brad Smith wrote:
> ping. Discussion died out. Can we please move this issue forward?
It's in
Philip
On 09/20/14 15:34, Philip Guenther wrote:
On Sat, Sep 20, 2014 at 11:28 AM, Mark Kettenis wrote:
Date: Sat, 20 Sep 2014 18:15:31 +
From: Miod Vallat
shmctl(2)/shmget(2)/shmat(2) all document
#include
#include
#include
as a requirement for calling these functions.
That was my first
> Date: Sun, 19 Oct 2014 09:25:51 +0200
> From: Matthieu Herrb
>
> On Thu, Oct 16, 2014 at 08:14:16PM +0200, Mark Kettenis wrote:
> > Hi Marc,
> >
> > Is there a reason why conditional includes (sinclude/-include) aren't
> > enabled in OpenBSD?
> >
> > I'm asking because the Xorg people now use
On Sun, Oct 19, 2014 at 09:25:51AM +0200, Matthieu Herrb wrote:
> On Thu, Oct 16, 2014 at 08:14:16PM +0200, Mark Kettenis wrote:
> > Hi Marc,
> >
> > Is there a reason why conditional includes (sinclude/-include) aren't
> > enabled in OpenBSD?
> >
> > I'm asking because the Xorg people now use it
On Thu, Oct 16, 2014 at 08:14:16PM +0200, Mark Kettenis wrote:
> Hi Marc,
>
> Is there a reason why conditional includes (sinclude/-include) aren't
> enabled in OpenBSD?
>
> I'm asking because the Xorg people now use it in one of the xserver
> Makefile. We could of course try to convince them to
Hi Marc,
Is there a reason why conditional includes (sinclude/-include) aren't
enabled in OpenBSD?
I'm asking because the Xorg people now use it in one of the xserver
Makefile. We could of course try to convince them to revert the
change they made. But it is a somewhat useful feature.
Thanks,
On Sun, Sep 21, 2014 at 16:20, Mark Kettenis wrote:
>> Date: Sat, 20 Sep 2014 12:34:42 -0700
>> From: Philip Guenther
>>
>> On Sat, Sep 20, 2014 at 11:28 AM, Mark Kettenis
> wrote:
>> >> Date: Sat, 20 Sep 2014 18:15:31 +
>> >> From: Miod Vallat
>> >>
>> >> > shmctl(2)/shmget(2)/shmat(2) all
> Date: Sat, 20 Sep 2014 12:34:42 -0700
> From: Philip Guenther
>
> On Sat, Sep 20, 2014 at 11:28 AM, Mark Kettenis
> wrote:
> >> Date: Sat, 20 Sep 2014 18:15:31 +
> >> From: Miod Vallat
> >>
> >> > shmctl(2)/shmget(2)/shmat(2) all document
> >> >
> >> > #include
> >> > #include
> >> > #
On Sat, Sep 20, 2014 at 11:28 AM, Mark Kettenis wrote:
>> Date: Sat, 20 Sep 2014 18:15:31 +
>> From: Miod Vallat
>>
>> > shmctl(2)/shmget(2)/shmat(2) all document
>> >
>> > #include
>> > #include
>> > #include
>> >
>> > as a requirement for calling these functions.
>>
>> That was my first
> Unfortunately it doesn't allow us to make everything in
> available though. So simply including from
> isn't the right solution.
Good point,
I didn't notice that, I was just testing sys/shm.h based on what
POSIX 2008 specification says and detected that this isn't working
as it should.
Oh, looks like man pages should be fixed too. There is no mention in
POSIX 2008 that sys/types.h and sys/ipc.h should be included:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/shmctl.html
http://pubs.opengroup.org/onlinepubs/9699919799/functions/shmget.html
http://pubs.opengroup.org/o
> Date: Sat, 20 Sep 2014 18:15:31 +
> From: Miod Vallat
>
> > shmctl(2)/shmget(2)/shmat(2) all document
> >
> > #include
> > #include
> > #include
> >
> > as a requirement for calling these functions.
>
> That was my first thought, but according to
> http://pubs.opengroup.org/onlinepubs
> shmctl(2)/shmget(2)/shmat(2) all document
>
> #include
> #include
> #include
>
> as a requirement for calling these functions.
That was my first thought, but according to
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_ipc.h.html
``The header shall define the uid_t, gid_t, mod
shmctl(2)/shmget(2)/shmat(2) all document
#include
#include
#include
as a requirement for calling these functions.
On Sat, Sep 20, 2014 at 01:24:02PM +0300, Matti Karnaattu wrote:
> Hello,
>
> I managed to get build error which was caused a missing include.
>
> test:
> =
Hello,
I managed to get build error which was caused a missing include.
test:
===
#include
int
main(void)
{
return 0;
}
===
And here is diff that fixes the bu
On Tue, Nov 20, 2012 at 16:08, Amit Kulkarni wrote:
> While porting boost-1.52.0 (latest boost) and checking affected ports, I
> came across this.
> In file included from /usr/include/sys/sysctl.h:42,
> I can patch and include sys/param.h in this graphics/mapnik port but
> sys/proc.h doesn't inclu
While porting boost-1.52.0 (latest boost) and checking affected ports, I came
across this.
c++ -o src/mapped_memory_cache.os -c -DHAVE_JPEG -pthread -ansi -Wall -pthread
-ftemplate-depth-300 -DOPENBSD -DBOOST_SPIRIT_THREADSAFE -DMAPNIK_THREADSAFE
-O3 -finline-functions -Wno-inline -DNDEBUG -DHA
Ok thanks.
On Wed, Apr 27, 2011 at 12:20 AM, Theo de Raadt wrote:
>> Maybe I am missing something but the following manpages don't really need
>> sys/types.h.
>
> you are wrong.
>
> You are only trying on OpenBSD.
>
> If only everything was OpenBSD.
>
> However, everything is not OpenBSD.
> Maybe I am missing something but the following manpages don't really need
> sys/types.h.
you are wrong.
You are only trying on OpenBSD.
If only everything was OpenBSD.
However, everything is not OpenBSD.
Maybe I am missing something but the following manpages don't really need
sys/types.h.
I compiled some small programs without sys/types.h.
thanks,
amit
Index: mincore.2
===
RCS file: /cvs/src/lib/libc/sys/mincore.2,v
retrieving re
/usr/src/sbin/init/init.c: In function 'new_session':
/usr/src/sbin/init/init.c:867: warning: implicit declaration of function 'err'
Trivial diff following:
Index: init.c
===
RCS file: /cvs/src/sbin/init/init.c,v
retrieving revision
On Wed, Feb 24, 2010 at 07:56:27PM -0700, Theo de Raadt wrote:
> > http://www.opengroup.org/onlinepubs/9699919799/
>
> And this is exactly the problem with POSIX.
>
> When was that change made?
It is the same kind of requirement as ISO C99 has for size_t. The
primary header for size_t is stddef.
> On Wed, Feb 24, 2010 at 07:27:27PM -0700, Theo de Raadt wrote:
> > > That said, sys/types.h is most likely not what is needed to
> > > make sys/mman.h self-contained, but that's a completely
> > > separate issue.
> >
> > By the way, where is it written that sys/mman.h has to be
> > self-containe
On Wed, Feb 24, 2010 at 07:27:27PM -0700, Theo de Raadt wrote:
> > That said, sys/types.h is most likely not what is needed to
> > make sys/mman.h self-contained, but that's a completely
> > separate issue.
>
> By the way, where is it written that sys/mman.h has to be
> self-contained?
>
> I bet
> That said, sys/types.h is most likely not what is needed to
> make sys/mman.h self-contained, but that's a completely
> separate issue.
By the way, where is it written that sys/mman.h has to be
self-contained?
I bet it is written exactly the other way around.
> It might be surprising, but for any semi-modern version of GCC
> applying the patch and compiling
>
> #include
> #include
>
> doesn't result in significant IO change compared to the unpatched
> version. The compiler is smart enough to recognise the normal include
> guard style and won't touch
On Wed, Feb 24, 2010 at 05:38:14PM -0700, Theo de Raadt wrote:
> > On Wednesday 24 February 2010 15:57:43 Ingo Schwarze wrote:
> > > In OpenBSD, we usually include headers in other headers if that
> > > is required by a relevant standard, in particular by POSIX.
> >
> > I don't know where you get
> On Wednesday 24 February 2010 15:57:43 Ingo Schwarze wrote:
> > In OpenBSD, we usually include headers in other headers if that
> > is required by a relevant standard, in particular by POSIX.
>
> I don't know where you get this idea from. Theo has made it pretty clear
> in the past that what you
On Wednesday 24 February 2010 15:57:43 Ingo Schwarze wrote:
> In OpenBSD, we usually include headers in other headers if that
> is required by a relevant standard, in particular by POSIX.
I don't know where you get this idea from. Theo has made it pretty clear
in the past that what you said above
Christopher Zimmermann wrote on misc@, Wed, Feb 24, 2010 at 08:53:28PM +0100:
> I just got some errors while trying to compile ptlib:
>
> error: type specifier omitted for parameter `size_t'
> [...]
>
> They resulted from size_t not being defined in sys/mmap.h
I guess you are talking about .
>
46 matches
Mail list logo
