zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: A.Main@dcs.warwick.ac.uk (Zefram),
	Zoltan Hidvegi <hzoli@cs.elte.hu>,
	zsh-workers@math.gatech.edu
Subject: Re: (NULL == 0) ?
Date: Sun, 26 May 1996 23:39:20 -0700	[thread overview]
Message-ID: <960526233923.ZM4366@candle.brasslantern.com> (raw)
In-Reply-To: Zoltan Hidvegi <hzoli@cs.elte.hu> "Re: (NULL == 0) ?" (May 27,  2:00am)

On May 27,  2:00am, Zoltan Hidvegi wrote:
} Subject: Re: (NULL == 0) ?
}
} > To answer the subject line, (NULL == 0) *is* guaranteed.  0 is the
} > representation of the null pointer constant in C.

Which means only that an ANSI/ISO C compiler guarantees that

    (pointer == 0)	returns 1 for a null pointer, 0 for non-null
    (pointer != 0)	returns 0 for a null pointer, 1 for non-null
    (pointer = 0)	assigns the null bit pattern

} > A lot of C code assumes [null bit pattern is 0], but it is broken.
} 
} Does anything guarantees that on those (theoretical) systems where NULL is
} not really zero, all static and external pointers are initialized to this
} NULL?

Yes, an ANSI/ISO C compiler must do this.

} Does anyone heard about such a Unix system?

This isn't a UNIX-or-not issue, it's a hardware issue.  I don't offhand
know of any such hardware that runs any well-known UNIX, but there are
probably some UNIX-like or UNIX-emulation operating systems for some
such hardware.

} I bet that if such a system
} exists memset would be just the easiest among many other problems.

True.  Very likely the C compilers on those systems at least have a
switch to cause them to reserve the address 0 and to treat pointers
that reference that address as NULL.  It would require extra code at
every pointer comparison, so it wouldn't be very efficient, but it
wouldn't be impossible.  I've never had direct experience with this,
though.

} A couple of other questions about Unix and C standards: does anything
} guarantee that a variable is always 8 * sizeof(var) bits long?

Not exactly.  ANSI/ISO C says something like this:

The value representable by (char)  is always AT LEAST  8 bits
                           (short)                    16
                           (long)                     32
and sizeof(char) is always 1, and sizeof(anything) is integral, and
sizeof(long) >= sizeof(int) >= sizeof(short) >= sizeof(char); and that
values returned by malloc/calloc/etc. point to memory correctly byte-
aligned for any type.

I don't recall whether sizeof(int) must be the same as one of (short)
or (long).  I don't think so (don't have an ANSI C book handy at the
moment).

But nothing prohibits, say, 11-bit chars with 33-bit longs.

} Does any Unix or C standard guarantee that ASCII is used (zsh assumes
} ASCII in many places)?

ANSI/ISO C guarantees that character constants are interpreted as the
corresponding ASCII numeric values when assigned or compared to integral
types, if that's what you mean.

} Does any Unix or C standard guarantees that an int always has at
} least 32 bits?

Definitely not.  See above.

Zsh does work when sizeof(int) != sizeof(long), e.g 4 != 8, because
I've run it on a DEC Alpha.  Well, older versions worked, anyway.

} Did anyone tried to compile zsh on a 80286 or 8086 Unix?

There's Linux for the 8086, you know ... terrifying.

Anybody out there running SCO UNIX care to compile in Xenix-compatible
286-mode and watch the fun?

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"



  reply	other threads:[~1996-05-27  6:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-05-25 14:38 clwords bugfix Zefram
1996-05-25 18:02 ` Richard Coleman
1996-05-25 20:52   ` Zefram
1996-05-25 21:25     ` (NULL == 0) ? Richard Coleman
1996-05-25 22:00       ` Zefram
1996-05-27  0:00         ` Zoltan Hidvegi
1996-05-27  6:39           ` Bart Schaefer [this message]
1996-05-27  7:29             ` anthony baxter
1996-05-27 13:07           ` Zefram
1996-05-27 22:00             ` Zoltan Hidvegi
1996-05-27 22:11               ` Zefram
1996-05-27 22:41                 ` Zoltan Hidvegi
1996-05-27 22:54                   ` Zefram
1996-05-28  4:54                     ` Bart Schaefer
1996-05-27 23:36                 ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=960526233923.ZM4366@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=A.Main@dcs.warwick.ac.uk \
    --cc=hzoli@cs.elte.hu \
    --cc=schaefer@nbn.com \
    --cc=zsh-workers@math.gatech.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).