printf

[Bartc]

And note 176 is:


Which I believe means that,

errno = 0;
p = malloc(n);
if(errno) /* p equals NULL */

And,

errno = 0;
p = malloc(n);
if(p == NULL) /* errno is non-zero */

It says errno *may* be set to nonzero by a library function whose docs do
not mention errrno.

This implies it is optional. And since there appears to be some confusion
about this, a programmer would have to be out of his mind to rely on errno
for checking the result of malloc instead of a NULL pointer return (apart
from the pita of having to set errno beforehand).

The only benefit of errno, if it was guaranteed to be set by malloc, would
be the ability to do a whole series of mallocs then check for error at the
end.

 

[vippstar]

It says errno *may* be set to nonzero by a library function whose docs do
not mention errrno.

This implies it is optional. And since there appears to be some confusion
about this, a programmer would have to be out of his mind to rely on errno
for checking the result of malloc instead of a NULL pointer return (apart
from the pita of having to set errno beforehand).

However, the standard mentions that a program can use errno for error
checking (in the footnote). Wouldn't that mean errno has to be set
when malloc returns NULL?

 

[James Kuyper]

However, the standard mentions that a program can use errno for error
checking (in the footnote). Wouldn't that mean errno has to be set
when malloc returns NULL?

No, it means that for many of the standard library functions, setting
errno to a particular value is mandatory under certain circumstances,
and checking the value of errno is useful when calling those functions.
That group does not include malloc().

 

[Bartc]

However, the standard mentions that a program can use errno for error
checking (in the footnote). Wouldn't that mean errno has to be set
when malloc returns NULL?

No. "A program that uses errno for error checking..." must mean where errno
is supported by the library function (ie. errno is mentioned in the docs). A
program can't rely on errno where errno is not mentioned in the docs, eg.
malloc.

Anyway, I've tried 3 compilers (lccwin32, mingw, and digital-mars) and only
gcc sets errno when malloc returns an error.

So either the other two are non-conforming, or there is no requirement to
set errno for malloc.

Either way, it makes relying on an errno!=0 return from malloc even less of
a good idea.

 

[Nick Keighley]

However, the standard mentions that a program can use errno for error
checking (in the footnote). Wouldn't that mean errno has to be set
when malloc returns NULL?

I think most people read this to mean a function *can* set errno
even if the standard doesn't explicitly say it must. But this doesn't
mean it *must* set errno. Besides who decides if its an error or
not. Why is passing zero to malloc() an error?

P.J.Plauger's implementaion of malloc() in "The Standard C Library"
doesn't set errno. It rounds up to a minimum "cell size".

 

[vippstar]

No. "A program that uses errno for error checking..." must mean where errno
is supported by the library function (ie. errno is mentioned in the docs). A
program can't rely on errno where errno is not mentioned in the docs, eg.
malloc.

Yes, you are right. Thanks for clearing this up.

 

[Flash Gordon]

Bartc wrote, On 06/09/08 12:03:

Anyway, I've tried 3 compilers (lccwin32, mingw, and digital-mars) and
only gcc sets errno when malloc returns an error.

The compiler distributed as part of mingw is gcc. So you have said, gcc
sets errno, but gcc and lcc-win32 don't...

gcc is only a compiler, malloc is (generally) provided by the library
and not the compiler. So I'm guessing you mean glibc on Linux sets
errno, mscrt.dll (or whatever it the MS library is called) and lcc-win32
don't.

So either the other two are non-conforming, or there is no requirement
to set errno for malloc.

It is not a conformance issue as the C standard does not require it.
glibc probably does it because unix98 requires it (according the the
docs I just read) and because it makes it easier for other library
functions which use malloc to have errno set.

Either way, it makes relying on an errno!=0 return from malloc even less
of a good idea.

Indeed.

 

[CBFalconer]

.... snip ...

Anyway, I've tried 3 compilers (lccwin32, mingw, and digital-mars)
and only gcc sets errno when malloc returns an error.

gcc doesn't set errno. The library code MAY do this. It doesn't
need to do so.

 

[CBFalconer]

.... snip ...

P.J.Plauger's implementaion of malloc() in "The Standard C Library"
doesn't set errno. It rounds up to a minimum "cell size".

This is wise, because it avoids the confusion (allowable) with an
error when malloc(0) occurs.

 

[Richard Bos]

However, the twinkletoes version does meet that standard. Re-read.

The return value does. The rest of the behaviour does not.

Richard

 

[Chris Dollin]

The return value does. The rest of the behaviour does not.

While I don't advocate library code issuing radical random removals,
I don't believe that standard prohibits this implementation, and
furthermore believe that it would be difficult (bordering on the
impossible) to write the standard in such a way as to disallow
the code above while permitting code that, say, keeps a file-based
rotating log of malloc calls.

That's what QualityOfImplementation is for: to apply Darwin's Razor
when Occam's is back in the shop for a good stropping.

 

[Richard Tobin]

[/QUOTE]

While I don't advocate library code issuing radical random removals,
I don't believe that standard prohibits this implementation

That rather the spoils the idea of undefined behaviour, doesn't it?
If demons may fly out of your nose even when you run a strictly
conforming program, everything's just a quality-of-implementation
issue.

-- Richard

 

[Kenny McCormack]

That's what QualityOfImplementation is for: to apply Darwin's Razor
when Occam's is back in the shop for a good stropping.

Off topic. Not portable. Cant discuss it here. Blah, blah, blah.

QOI is clearly OT here. I think you've been around long enough to know
that by now.

 

[CBFalconer]

The return value does. The rest of the behaviour does not.

I disagree. It always fails. It also has undefined side-effects.

 

[CBFalconer]

That rather the spoils the idea of undefined behaviour, doesn't it?
If demons may fly out of your nose even when you run a strictly
conforming program, everything's just a quality-of-implementation
issue.

Read up on what is guaranteed from the 'system' call. Remember
there is no guarantee that this runs on *ix.

 

[jameskuyper]

Read up on what is guaranteed from the 'system' call. Remember
there is no guarantee that this runs on *ix.

This is proposed as an implementation of the C standard library;
presumably it would only be used for implementations where the system
call actually works, for some suitable definition of "works". Some
standard library functions can be written in strictly conforming C
code (except, of course, for the fact that strictly conforming C code
isn't allowed to name functions with those names). However, malloc()
is not one of those functions, and no claim was made about this
"implementation" of malloc() being portable.

 

[Richard Bos]

I disagree. It always fails. It also has undefined side-effects.

If you start allowing that, you should also allow

erwHdlk#je ;kljdsl 342o44,dfg fwiirto llrll jrid7 686!jk

as the output of

printf("Hello, world!");

It is, after all, the required output of that statement - interspersed
with some "undefined side-effects".

Forsooth, yonder way madness lieth, methinks.

Richard

 

[CBFalconer]

.... snip ...


If you start allowing that, you should also allow

erwHdlk#je ;kljdsl 342o44,dfg fwiirto llrll jrid7 686!jk

as the output of

printf("Hello, world!");

It is, after all, the required output of that statement -
interspersed with some "undefined side-effects".

Forsooth, yonder way madness lieth, methinks.

Ahh - there you have a valid definition of programming.