|
Home > Archive > Unix Programming > March 2004 > fprintf question
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| #include <stdio.h>
main()
{
fprintf(stderr,"%s\n", 0);
}
This piece of code on HPUX print out nothing.
This is what I want.
But on RedHat 8.0
This piece of code print out
(null)
I am porting code from HPUX to RedHat 8
This behavior cause me lots of grief.
How do I make RedHat to print out nothing.
Thanks,
Terry
| |
| Rich Teer 2004-03-18, 8:36 pm |
| On Thu, 18 Mar 2004, tpang wrote:
> #include <stdio.h>
> main()
> {
> fprintf(stderr,"%s\n", 0);
> }
>
> This piece of code on HPUX print out nothing.
> This is what I want.
HPUX is broken; dereferencing a NULL pointer provokes undefined
behaviour.
> But on RedHat 8.0
> This piece of code print out
> (null)
>
> I am porting code from HPUX to RedHat 8
> This behavior cause me lots of grief.
>
> How do I make RedHat to print out nothing.
Write your code correctly. For example:
if (s != NULL)
fprintf (stderr, "%s\n", s);
I remember porting a large project from HPUX to Solaris,
and the code was riddled with these stupid NULL pointer
dereferences. HPUX's default behaviour of allowing this
enables these bugs to go undiscovered (dereferencing a
NULL pointer is always (or nearly so) a bug).
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
| |
| Barry Margolin 2004-03-18, 8:36 pm |
| In article <Pine.SOL.4.58.0403181457410.103@zaphod.rite-group.com>,
Rich Teer <rich.teer@rite-group.com> wrote:
> On Thu, 18 Mar 2004, tpang wrote:
>
>
> HPUX is broken; dereferencing a NULL pointer provokes undefined
> behaviour.
Since it's undefined behavior, any result is possible, so printing out
nothing cannot be considered "broken". It's a lack of a helpful feature
at worst. I suspect the HP stdio programmer thought he was doing
something useful by treating a null pointer equivalently to an empty
string.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| joe@invalid.address 2004-03-18, 8:36 pm |
| Rich Teer <rich.teer@rite-group.com> writes:
> On Thu, 18 Mar 2004, tpang wrote:
>
>
> HPUX is broken; dereferencing a NULL pointer provokes undefined
> behaviour.
>
>
> Write your code correctly. For example:
>
> if (s != NULL)
> fprintf (stderr, "%s\n", s);
>
> I remember porting a large project from HPUX to Solaris,
> and the code was riddled with these stupid NULL pointer
> dereferences. HPUX's default behaviour of allowing this
> enables these bugs to go undiscovered (dereferencing a
> NULL pointer is always (or nearly so) a bug).
It's been a while for me, but as I recall there's a compiler/linker
option on HP which disallows dereferencing null pointers. At least on
HP-UX 10.20 it's -z.
Before porting it might be worth building with that flag and let the
system find this particular bug.
Joe
--
Don't worry, be happy
- Bobby McFerrin
| |
| Rich Teer 2004-03-18, 10:35 pm |
| On Thu, 18 Mar 2004, Barry Margolin wrote:
> Since it's undefined behavior, any result is possible, so printing out
> nothing cannot be considered "broken". It's a lack of a helpful feature
I respectfully disagree. Although it doesn't break any standards,
I think this behaviour can be considered broken, as in "doesn't do
the sensible thing".
> at worst. I suspect the HP stdio programmer thought he was doing
> something useful by treating a null pointer equivalently to an empty
> string.
Doubtless, although it's not just the stdio stuff that's iffy.
IIRC, any dereferencing of a NULL pointer is allowed by default.
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
| |
| Erik Max Francis 2004-03-18, 10:35 pm |
| Rich Teer wrote:
> I respectfully disagree. Although it doesn't break any standards,
> I think this behaviour can be considered broken, as in "doesn't do
> the sensible thing".
If a programmer has written Standards-violating code, it's his code
that's broken, not the implementation that just happens to not do
something he wanted, because necessarily different programmers will not
agree on what they wanted to have happen, since it's left open by the
Standard (in fact very bad things can happen since the behavior is
undefined, rather than merely unspecified or implementation-defined).
--
__ Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ Life imitates art far more than art imitates life.
-- Oscar Wilde
| |
| joe@invalid.address 2004-03-18, 10:35 pm |
| Rich Teer <rich.teer@rite-group.com> writes:
> On Thu, 18 Mar 2004, Barry Margolin wrote:
>
>
> I respectfully disagree. Although it doesn't break any standards,
> I think this behaviour can be considered broken, as in "doesn't do
> the sensible thing".
Unfortunatly the sensible thing is in the eye of the implementor. If I
remember correctly we put in a call to HP about this, and were told
that they felt they were forced to do it this way because of all the
libraries they had to use which dereferenced null pointers. It would
have been much more expensive for them to fix all the libraries, do
all the regression tests, etc, than to just allow it.
That may or may not be true (I have no idea how much the tech support
guy we were paying so much for actually knew about anything), but it
doesn't sound impossible.
Joe
--
Don't worry, be happy
- Bobby McFerrin
| |
| Rich Teer 2004-03-18, 10:35 pm |
| On Fri, 19 Mar 2004 joe@invalid.address wrote:
> Unfortunatly the sensible thing is in the eye of the implementor. If I
> remember correctly we put in a call to HP about this, and were told
> that they felt they were forced to do it this way because of all the
> libraries they had to use which dereferenced null pointers. It would
Sounds like handwaving to me. The libraries in question were either
written in house, or 3rd party. In the latter case, other vendors
are prsumably using similar code, without resortig to nasty things
like this.
> guy we were paying so much for actually knew about anything), but it
> doesn't sound impossible.
I agree. Plausible - but not very sensible.
To me, the bottom line is this: dereferencing a NULL pointer is
a bug in one's application. Speaking as a programmer, I'd rather
find out about bugs as soon as possible - and masking these errors
defeats that purpose. If nothing else, having this behaviour being
the default encourages bad programming. This is an area where I'm
happy to go on record as saying that Linux does (one of the) right
thing(s). Solaris also does a right thing: when dereferencing NULL
pointers, it sends the offending process a SIGSEGV (there are ways
to change this behaviour).
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
| |
| Lorinczy Zsigmond / Domonyik Mariann 2004-03-19, 9:41 am |
| tpang wrote:
> #include <stdio.h>
> main()
> {
> fprintf(stderr,"%s\n", 0);
> }
>
> This piece of code on HPUX print out nothing.
> This is what I want.
>
> But on RedHat 8.0
> This piece of code print out
> (null)
>
> I am porting code from HPUX to RedHat 8
> This behavior cause me lots of grief.
>
> How do I make RedHat to print out nothing.
try:
fprintf (stderr, "%.*s\n", 0, 0);
| |
| Casper H.S. Dik 2004-03-19, 9:41 am |
| tpang99@hotmail.com (tpang) writes:
>#include <stdio.h>
>main()
>{
> fprintf(stderr,"%s\n", 0);
>}
>This piece of code on HPUX print out nothing.
This piece of code causes undefined behaviour; on Solaris
it prints:
Segmentation fault (core dumped)
(You can map address 0 and get the same behaviour as HP/UX)
as it bloody well should.
>This is what I want.
HP/UX is broken because it allows you to write broken code.
>But on RedHat 8.0
>This piece of code print out
>(null)
Also completely legal behaviour, but brokeness is not
"in your face". A broken program should fail mor ereliably :-)
>I am porting code from HPUX to RedHat 8
>This behavior cause me lots of grief.
>How do I make RedHat to print out nothing.
Fix your code and make it portable. There is nothing
at the end of a NULL pointer so don't tell anybody to go
and look there.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
| |
| Casper H.S. Dik 2004-03-19, 9:41 am |
| Rich Teer <rich.teer@rite-group.com> writes:
>On Thu, 18 Mar 2004, Barry Margolin wrote:
[color=darkred]
>I respectfully disagree. Although it doesn't break any standards,
>I think this behaviour can be considered broken, as in "doesn't do
>the sensible thing".
[color=darkred]
>Doubtless, although it's not just the stdio stuff that's iffy.
>IIRC, any dereferencing of a NULL pointer is allowed by default.
I think it's because HP/UX maps address 0 by default, not
because of some insight by the stdio programmer.
That is what happened with Red Hat's C library where the program
tried to be helpful.
I think Sun did that in SunOS 3.x/4.x as well because it was "helpful"
or, more likely, because fixing *all* NULL dereferences in one go was
too much work.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
| |
| Alex Colvin 2004-03-19, 2:35 pm |
| >> fprintf(stderr,"%s\n", 0);[color=darkred]
well, if you need this behavior, you could implement your own variant of
fprintf. If you don't worry about widths and precisions, it's not hard.
--
mac the naïf
| |
| Walt Fles 2004-03-19, 2:35 pm |
| fprintf(stderr,"\n" );
tpang wrote:
> #include <stdio.h>
> main()
> {
> fprintf(stderr,"%s\n", 0);
> }
>
> This piece of code on HPUX print out nothing.
> This is what I want.
>
> But on RedHat 8.0
> This piece of code print out
> (null)
>
> I am porting code from HPUX to RedHat 8
> This behavior cause me lots of grief.
>
> How do I make RedHat to print out nothing.
>
> Thanks,
> Terry
| |
| Rich Teer 2004-03-19, 6:37 pm |
| On Fri, 19 Mar 2004, Casper H.S. Dik wrote:
> I think Sun did that in SunOS 3.x/4.x as well because it was "helpful"
> or, more likely, because fixing *all* NULL dereferences in one go was
> too much work.
Right - it's also probably why Sun supplys /usr/lib/0@0.so.1:
"just in case". But even that should only be used as a quick
and dirty hack while the application's code is fixed.
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
| |
| James Antill 2004-03-20, 8:32 pm |
| On Fri, 19 Mar 2004 17:59:03 +0000, Alex Colvin wrote:
>
> well, if you need this behavior, you could implement your own variant of
> fprintf. If you don't worry about widths and precisions, it's not hard.
A much better idea would be to use one of the many pre-built portable
printf's there is a list of free ones at:
http://www.and.org/vstr/printf_comparison.html
Using Vstr it's also trivial to change the behaviour of what...
foo("%s", (void *)NULL)
....prints. Note that the first version will _very_ likely break
anyway on a 64bit platform.
--
James Antill -- james@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/
| |
| Paul Pluzhnikov 2004-03-20, 8:32 pm |
| Casper H.S. Dik <Casper.Dik@Sun.COM> writes:
> HP/UX is broken because it allows you to write broken code.
HP-UX allows reads from NULL by default, but has an option to
disallow this broken behaviour:
$ echo "int main() { int *ip = 0; return *ip; }" > junk.c
$ cc junk.c && ./a.out; echo $?
0
$ cc -z junk.c && ./a.out; echo $?
Segmentation fault (core dumped)
139
> Fix your code and make it portable.
I second that. Also smack the developer who wrote that code.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| Greg Estep 2004-03-21, 8:34 pm |
|
<joe@invalid.address> wrote in message
news:m31xnpvgmv.fsf@invalid.address...
> Rich Teer <rich.teer@rite-group.com> writes:
>
>
> It's been a while for me, but as I recall there's a compiler/linker
> option on HP which disallows dereferencing null pointers. At least on
> HP-UX 10.20 it's -z.
The -z option has been an available option to the HP-UX compiler for as long
as I can remember.
--
Greg Estep
|
|
|
|
|