HDTenEightyP/NetNews huggingface dataset:
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: this unsigned business
Date: Sat, 3 Oct 1992 22:37:09 GMT
Organization: U of Toronto Zoology

In article <1992Oct2.163051.26791@waggen.twuug.com> alpha@waggen.twuug.com (Joe Wright) writes:
>Casting an int to unsigned does not change the representation.

Wrong.  Casting a *positive* int to unsigned does not change the
representation.  Casting a negative int might have to, because the
results of this cast are very precisely defined but the representation
of negative integers is not.  No change of representation is needed
on two's-complement machines.  Machines which use one's-complement or
signed-magnitude representations for integers *will* have to change
the data bits in such a case.

Yes, Virginia, a cast is a *conversion*, not a "view the bits differently"
operator.
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: this unsigned business
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Thu, 1 Oct 1992 02:57:24 GMT

In article <711@mtndew.Tustin.CA.US> friedl@mtndew.Tustin.CA.US (Stephen Friedl) writes:
>     Let's say that I've got an int whose legal range is 0 to 100,
>and I want to validate it (say) upon entry to a function.  Is this
>a portable way to do it?
>  foo(v) int v; {
>    if ( (unsigned int) vu > 100) printf("value out of range!\n");
>    /* must be valid */

It's portable because conversions from int to unsigned int are defined
and because MAX_UINT is sufficiently large for your purpose.

>     Note that I am not looking for the aesthetics of this -- it's
>a trick that will just confuse somebody

You bet!  After all, you print "value out of range!\n" and then fall
through to the next line, assuming "must be valid" :-)
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."
Newsgroups: comp.std.c
From: bill@twwells.com (T. William Wells)
Subject: Re: strtoul on negative numbers
Date: Thu, 1 Oct 1992 07:59:37 GMT
Organization: None, Mt. Laurel, NJ

In article <1992Sep30.234808.19678@ptcburp.ptcbu.oz.au> michi@ptcburp.ptcbu.oz.au (Michael Henning) writes:
: All implementations I have seen return ULONG_MAX - 1.

This is the correct behavior.

: I believe that this is incorrect behaviour.
: -2 is not a value representable in an unsigned long, in my opionion.

So? Who says that the value -2 is represented?

What *is* represented is the value of 2, negated. For C,
operations like add and subtract (and negate, considered as 0-x)
on unsigned types are defined as modular arithmetic where the
result is always kept in the range 0..max-1.

---
Bill                            { rutgers | decwrl | telesci }!twwells!bill
bill@twwells.com
From: friedl@mtndew.Tustin.CA.US (Stephen Friedl)
Newsgroups: comp.std.c
Subject: Re: Change to time() fn?
Date: 28 Sep 92 18:22:29 GMT
Organization: Steve's Personal machine / Tustin, CA

The recent spate of articles on the implementation of times encourages
me to post a reminder to all UNIX folks -- do NOT use /long/ when you
mean /time_t/.

In my otherwise highly portable code, I got sloppy because I didn't
want to mess around with #include <sys/types.h> everywhere, but I
got burned on the DEC Alpha machine.  It is a 64-bit machine, and
their time_t is a 32-bit /int/, not a 64-bit long.

Be warned and don't make the bozo blunder I made.

     Stephen

-- 
Stephen J Friedl | Software Consultant | Tustin, CA |     +1 714 544-6561
3b2-kind-of-guy  | I speak for me ONLY |   KA8CMY   | uunet!mtndew!friedl
 
Attorneys are paranoid because they assume everybody else is dishonest too
Newsgroups: comp.std.c
From: bill@twwells.com (T. William Wells)
Subject: Re: strtoul on negative numbers
Date: Thu, 1 Oct 1992 07:51:29 GMT
Organization: None, Mt. Laurel, NJ

In article <1992Sep30.175835.7972@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
: What is the result of
:
:     strtoul("-2", (char**)0, 10)
:
: The description is clear that the minus sign is allowed.
: The relevant sentence describing the result is.
:
: "If the correct value is outside the range of representable values
: ULONG_MAX is returned ..."
:
: My reading of this is that it requires ULONG_MAX to be returned,
: but others think that -2 is a representable value (equal to
: ULONG_MAX-1) and so ULONG_MAX-1 should be returned.

The definition for strtoul says that one converts the number (to
an unsigned long) ignoring the minus sign and then negates it.
Negation is defined for all values of an unsigned type, resulting
in ULONG_MAX+1-x, where x is 2, for this case.

---
Bill                            { rutgers | decwrl | telesci }!twwells!bill
bill@twwells.com
Newsgroups: comp.std.c
From: dhesi@cirrus.com (Rahul Dhesi)
Subject: Re: Change to time() fn?
Organization: Cirrus Logic Inc.
Date: Tue, 29 Sep 1992 22:21:57 GMT

In <704@mtndew.Tustin.CA.US> friedl@mtndew.Tustin.CA.US (Stephen
Friedl) writes:

>The recent spate of articles on the implementation of times encourages
>me to post a reminder to all UNIX folks -- do NOT use /long/ when you
>mean /time_t/.

The old portability versus standard-conformance conflict.  

time_t is standard-conformant;  so it will work on nearly 100% of
new systems, and on about 30% of old ones.

long is portable;  so it will work on nearly 99.7% of new systems,
and on about 100% of old ones.

So:  Be as standard-conformant as you can; be as portable if you wish;
but realize that it's very, very hard to be all of both.

A solution:  A standardized type name should be accompanied by a
standardized #define.  Then people like me, who want to be both
portable and standard-conformant, can do this:

    /* portable *and* standard-conformant in a parallel universe */
    #ifdef _HAVE_TIME_T
    # define TIME_T	time_t
    #else
    # define TIME_T	long
    #endif

Note that such accompanying defines are already needed to avoid
duplicate typedefs, when the same thing is defined in multiple standard
include files.  So long as they are needed, it would be worth while (in
the next standard, ANSI C 1999 or so) to have official names for them.
-- 
Rahul Dhesi <dhesi@cirrus.com>
also: dhesi@rahul.net
From: bill@twwells.com (T. William Wells)
Newsgroups: comp.std.c
Subject: Re: struct hack, and other out-of-array references
Date: 1 Oct 92 10:15:17 GMT
Article-I.D.: twwells.BvFttL.KHM
Organization: None, Mt. Laurel, NJ

In article <1992Oct1.070345.14854@sq.sq.com> msb@sq.sq.com (Mark Brader) writes:
: > Consider the question: what is (char*)&a[0][1] - (char *)&a[0][0]?
: > sizeof(&a[0][0]) of course.  Carried out repeatedly, one sees that
: > each subelement of a is at the expected offset from the start of
: > a.  The only question you might have is: what is (char*)&a[x][0] -
: > (char*)&a[x-1][y-1], where y is the number of elements in a[x].
: > The rules on sizeof and contiguity of objects require that to be
: > sizeof(&a[0][0]) as well.
:
: For ease of discussion I'll assume that a[0][0] has type int.
:
: The above is correct as far as it goes.  And it implies that you can do
:
:       int *p = &a[x-1][y-1];
:       p = (int *) ((char *) p + 2 * sizeof (int));
:
: and *p will now be a[x][1].  But you _cannot_ replace the second
: statement with a simple "p += 2;" and expect the same result.  This
: is the thrust of the Interpretation Ruling that was quoted earlier
: in the thread.  You really have to make the excursion into char *
: and back:  The standard requires that "a" be treatable as an array
: of bytes, and therefore as an array of any character type, but not
: as an array of int.

Sorry, but no. If you can treat it as an array of bytes, you can
treat it as an array of *anything*, provided that you don't
violate alignment restrictions. That's the point of the rules on
pointer casting and pointer arithmetic. (Alternately, if we were
to imagine that your comment was true, there isn't anything
special about the int* type; it would be equally illegal to index
past the subarray with char* pointers.)

: > In other words, these pointers are just pointers into an array,
: > and correspond in the expected way to pointers into the doubly
: > indexed array.
:
: They point to locations which are located as they would be in a
: simple array, but the permitted operations are not the same.

The standard certainly doesn't say that and, as far as I know
(not having the official interpretations, only Doug Gwyn's
comments), the interpretation talks about indexing past
subarrays, not about manipulating the converted pointers. If you
have the text of the interpretation ruling and it says otherwise,
I'll recant; otherwise, I see no reason to change my opinion.

---
Bill                            { rutgers | decwrl | telesci }!twwells!bill
bill@twwells.com
Newsgroups: comp.std.c
From: greyham@research.canon.oz.au (Graham Stoney)
Subject: Re: Change to time() fn?
Organization: Canon Information Systems Research Australia
Date: Fri, 2 Oct 1992 02:34:55 GMT

alpha@waggen.twuug.com (Joe Wright) writes:
>Please remember that floats (and doubles) are approximates.
>The value of time_t must be precise.  We don't like a value
>which says 'it's almost 5 o'clock'.  Precision requires
>time_t to be an integer.

But time is a continuum; it is not discrete. Integers, floats and doubles all
store discrete values, so none of them can precisely represent all values of
time, not even in a small fixed interval. You may not like a value that says
"it's about 5 oclock", but that's the best we can do. A floating point time_t
will allow finer resolution for times near the epoch than an integral one, and
less resolution for times far from the epoch. An integral time_t abruptly
becomes unable to represent the time at all as you move away from the epoch,
whereas the precision of the floating point time_t degrades gracefully. Since
we are normally more interested in times near the present than the distant past
or future, this is a reasonable tradeoff. I think this was the original
poster's point.

regards,
Graham
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: timezone info left out of time.h?
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Sat, 3 Oct 1992 04:24:03 GMT

In article <PDS.92Oct1193222@lemming.webo.dg.com> pds@lemming.webo.dg.com (Paul D. Smith) writes:
>the standard allows an implementation to either be aware of timezone info or
>not (by setting tm_isdst to a negative value and returning NULL from gmtime).
>[...] does anyone have any opinions on why some method of determining the
>local timezone displacement from UTC was not included in the standard?

Your local timezone displacement (in Massachusetts) now is -4 hours but next
month will be -5 hours.  It is only meaningful to compute local time for a
particular instant of time.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."
Newsgroups: comp.std.c
From: phil@ux1.cso.uiuc.edu (Phil Howard)
Subject: Re: strtoul on negative numbers
Organization: University of Illinois at Urbana
Date: Fri, 2 Oct 1992 21:01:12 GMT

bill@twwells.com (T. William Wells) writes:

>The definition for strtoul says that one converts the number (to
>an unsigned long) ignoring the minus sign and then negates it.
>Negation is defined for all values of an unsigned type, resulting
>in ULONG_MAX+1-x, where x is 2, for this case.

I take it that your interpretation is saying that strtoul() is supposed
to return an unsigned integer with the value ULONG_MAX+1-x whenever an
input number has the form of a "-" followed by a properly formed unsigned
quantity.

If the representation given is outside of the range of ULONG_MAX (the part
following the "-", not including it) then ULONG_MAX would be returned.  But
what if such an out of range number is preceeded by a "-"?  Do we return
the value ULONG_MAX+1-ULONG_MAX (which would be just 1) or do we return the
value ULONG_MAX?
Newsgroups: comp.std.c
From: bfhalls@vela.acs.oakland.edu (HALLS BRADLEY F)
Subject: ptr to a function?
Organization: Oakland University, Rochester MI.
Date: Sat, 26 Sep 1992 05:25:09 GMT

Dear c-gurus:

  Please forgive me for asking such an ignorant question on my first post,
but I'm in a bit of a jam. I need to finish a program that requires me (I
think) to pass the address of a function to another function. I want to do
something like:

func1 (float X, float (*funcptr) (float Y));	/* declaration for func1   */
						/* passed a float and	   */
						/* addr of func2, which	   */
						/* returns and is passed   */
						/* a float.		   */
...

funcptr = &func2 (float Y);			/* funcptr = addr of func2 */

...

Z = *funcptr (float Y);				/* call the func at addr   */
 						/* *funcptr		   */

I know the syntax is all screwed up, but if you can tell what I'm after,
any help would be greatly appreciated. Thanks in advance.

--Brad.
 

-- 
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Brad Halls                                "Still looking for witty quote."
Computer Science Grad Student              -me         
Oakland University
Rochester, Michigan
bfhalls@vela.acs.oakland.edu

^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Newsgroups: comp.std.c
From: david@cs.uow.edu.au (David E A Wilson)
Subject: Re: C-formattors (problems with very long lines)
Organization: Dept of Computer Science, Wollongong University, Australia
Date: Sat, 3 Oct 1992 05:45:18 GMT

hermann@uran.informatik.uni-bonn.de (Hermann Stamm) writes:
>Below you can find the little prog I am using. It detects both,
>if a ; is inside "..." and inside ' ' . If so, it doesn't insert
>the '\n' after the ; otherwise it does.
>The question now is, does the below program correctly transforms
>any compilable C-source into also compilable C-source.

Code deleted for brevity.

The short answer is no - your program fails on a set of programs
in which an odd number of ' or " appear inside " or ' or /* */.
For example:

main() { char *x = "';"; char y = ';'; char z = '"'; }

when run through your program results in:

main() { char *x = "';"; char y = ';
'; char z = '"'; }

Your code fails to break at the three valid `;' and breaks at one invalid `;'.
-- 
David Wilson				(042) 21 3802 voice, (042) 21 3262 fax
Dept Comp Sci, Uni of Wollongong	david@cs.uow.edu.au
From: friedl@mtndew.Tustin.CA.US (Stephen Friedl)
Newsgroups: comp.std.c
Subject: this unsigned business
Date: 30 Sep 92 22:12:00 GMT
Organization: Steve's Personal machine / Tustin, CA

Hi Folks,

     This whole unsigned business has got me thinking about the
portability aspects of a little trick, and I was wondering about
the net.at.large's opinion of it.

     Let's say that I've got an int whose legal range is 0 to 100,
and I want to validate it (say) upon entry to a function.  Is this
a portable way to do it?

	foo(v)
	int v;
	{
		if ( (unsigned int) vu > 100)
			printf("value out of range!\n");

		/* must be valid */

     Note that I am not looking for the aesthetics of this -- it's
a trick that will just confuse somebody -- just whether it is portable
or not.  I know that it works on my machine, which doesn't prove
much at all.

     Thoughts?

     Stephen

-- 
Stephen J Friedl | Software Consultant | Tustin, CA |     +1 714 544-6561
3b2-kind-of-guy  | I speak for me ONLY |   KA8CMY   | uunet!mtndew!friedl
 
Attorneys are paranoid because they assume everybody else is dishonest too
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Newsgroups: comp.std.c
Subject: Re: Change to time() fn?
Date: 30 Sep 92 01:10:04 GMT
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo

In article <1992Sep29.222157.23749@cirrus.com> dhesi@cirrus.com (Rahul Dhesi) writes:
>long is portable;  so it will work on nearly 99.7% of new systems,
>and on about 100% of old ones.

Maybe somewhat less than 99.7% of new systems, as new systems move towards
encoding the bits of a double in a funny manner.

>A solution:  A standardized type name should be accompanied by a
>standardized #define.

Or a non-standardized #define or typedef or any other implementation solution
to yield standardized BEHAVIOR.

>Then people like me, who want to be both
>portable and standard-conformant, can do this:
>    /* portable *and* standard-conformant in a parallel universe */
>    #ifdef _HAVE_TIME_T
>    # define TIME_T	time_t
>    #else
>    # define TIME_T	long
>    #endif

That is neither portable nor standard-conformant because _HAVE_TIME_T is in
the implementation's namespace, and the implementation can choose to define
it or not define it arbitrarily, just to mess you up if it wishes.

However, #ifdef and a related definition in the user's namespace are indeed
a reasonable solution (for contending with the mess that it has to contend
with).  Here's something a bit simpler:

  #ifndef HAVE_TIME_T
  typedef long time_t;
  #endif

>Note that such accompanying defines are already needed to avoid
>duplicate typedefs, when the same thing is defined in multiple standard
>include files.

Huh?  If an implementation chooses to define __TIME__ for that purpose,
instead of the name you liked, where does that leave you?
If an implementation has the standard headers in RAM while the compiler
is running, and has its own array of booleans to remind it of what it
has already included, then it would not have to define anything at all.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."
From: gay@selkirk.sfu.ca (Ian D. Gay)
Newsgroups: comp.std.c
Subject: Re: Sorting of x,y coords.
Date: 2 Oct 92 16:25:06 GMT
Article-I.D.: sfu.gay.718043106
Organization: Simon Fraser University, Burnaby, B.C., Canada

prangba@halcyon.com (Bruce Prang) writes:

>Does anybody out there in net-land have any routines, or know where I
>can get some, for sorting x,y coordinate pairs. I want to sort these
>pairs so the resulting order is circular. That is, if you were to
>connect all of the points with straight lines none of these lines would
>cross.

Compute arctan(y/x) and use the result as your key.
Newsgroups: comp.std.c
From: phil@ux1.cso.uiuc.edu (Phil Howard)
Subject: realloc() unable to allocate
Organization: University of Illinois at Urbana
Date: Fri, 2 Oct 1992 21:26:08 GMT

If realloc() is unable to allocate the larger space desired, what happens?

7.10.3.4 says:

    "...  If the space cannot be allocated, the object pointed to by ptr
    is unchanged.  ..."

and

    "The realloc function returns either a null pointer or a pointer to the
    possible moved allocated space".


While it SEEMS apparent that the meaning is that if realloc() cannot allocate
more space, it would return the NULL pointer (and to reuse the original object,
the pointer to it must be retained by the caller), I don't see any literal
statement to that effect.  Is there a concensus?
Newsgroups: comp.std.c
From: hermann@uran.informatik.uni-bonn.de (Hermann Stamm)
Subject:  Re: Re: C-formattors (problems with very long lines)
Reply-To: hermann@uran.informatik.uni-bonn.de (Hermann Stamm)
Organization: Praktische Informatik III
Date: Wed, 30 Sep 1992 09:29:07 GMT


tomc@siesoft.co.uk (Tom Crossland) writes:
> 
> hermann@uran.informatik.uni-bonn.de (Hermann Stamm) writes:
> :    - insert a '\n' after each ';' found
> 
> What about things like for(a=1; a<MAX; a*=2)...
> would become
> 
> for(a=1;
> a<MAX;
> a*=2)...
> 
> It should still compile, but it's hardly "beautified"
> 

Perhaps this is not beautified, but it 
  a) works even on C-Sources with very long lines 
  b) can be beautified by a standard beautifier in
     a second step
and it is a great help in debugging of lines with length
greater than i.e. xterm can capture.

Is there any fixed upper limit for line-length in the 
ANSI-C-standard ?

The more important question I think, is, what is the reason for 
standard C-beautifiers to break -> in the middle for long lines
(resulting in a compiler-error).
Do they use a fixed length buffer for handling logical lines?

--------------------------------------------------------------

fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
> hermann@uran.informatik.uni-bonn.de (Hermann Stamm) writes:
> 
> >I wrote my own simple "C-beautifier", which simply does the
> >following:
> >
> >   - discard empty lines
> >   - insert a '\n' after each ';' found
> >
> >This works fine, but now I have 2 questions:
> >
> >  1. Is this a correct transformation of any C-Source ?
> 
> No. You need to make sure that you don't insert newlines into string
> or character literals that may contain semi-colons.

Sorry, you are right!
Below you can find the little prog I am using. It detects both,
if a ; is inside "..." and inside ' ' . If so, it doesn't insert
the '\n' after the ; otherwise it does.

The question now is, does the below program correctly transforms
any compilable C-source into also compilable C-source.


Bye,

   Hermann.

---------------------------------------------------------------

#include <stdio.h>
#include <stdlib.h>

int main(int argc,char *argv[])
  {
  FILE *source,*target;
  char c;
  long z1,z2,l;

  if (argc!=3)
    {
    fprintf(stderr,"Formtat:  cb infile outfile\n");
    exit(1);
    }

  if (NULL == (source = fopen(argv[1],"r")))
    {
    fprintf(stderr,"file not found !\n");
    exit(2);
    }

  if (NULL == (target = fopen(argv[2],"w")))
    {
    fprintf(stderr,"target cannot be created !\n");
    exit(3);
    }

  z1=z2=l=0;
  while ((c=getc(source))!=-1)
    {
    if (c==34) z1^=1;
    if (c==39) z2^=1;
    if (c=='\n')
      {
      if (l>0)
        {
        putc(c,target);
        l=0;
        }
      }
    else
      {
      putc(c,target);
      l++;
      if ((c==';') && (z1==0) && (z2==0))
        {
        putc('\n',target);
        l=0;
        }
      }
    }

  fclose(target);
  fclose(source);

  return(0);
  }


Newsgroups: comp.std.c
From: eggert@twinsun.com (Paul Eggert)
Subject: Re: should abs() be 'uint'?
Organization: Twin Sun, Inc
Date: Mon, 28 Sep 1992 18:06:17 GMT

uddeborg@sisu.se (Goeran Uddeborg) writes:

>In article <Bv7uL7.2IK@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>>It would make sense.  Unfortunately, that's not the way abs() was defined
>>originally... and changing it now might break a lot of code.

>It could hardly break a lot of code, could it?

Henry Spencer's right.  Under the proposed change `abs(0) <= -1' would yield 1.
This kind of non-mathematical behavior might well break things.
Newsgroups: comp.std.c