What is wrong with this c-program?

Discussion in 'C Programming' started by Albert van der Horst, Dec 25, 2013.

  1. Albert van der Horst

    Seebs Guest

    My best *guess* would be 8, but I would hate to rely on that, because
    it's sometimes wrong.
    Sure. But at least I know for sure what a char *is*. I can't be as confident
    that I know what someone meant when they called something a "byte".

    -s
     
    Seebs, Dec 27, 2013
    #21
    1. Advertisements

  2. No, CHAR_BIT.

    [...]
     
    Keith Thompson, Dec 27, 2013
    #22
    1. Advertisements

  3. Albert van der Horst

    Jorgen Grahn Guest

    My practical experience, too, today. Although the /very/ experienced
    can see that it's unlikely that a widely used version of gcc, for a
    popular target and with commonly used flags has spectacular bugs.

    /Jorgen
     
    Jorgen Grahn, Dec 29, 2013
    #23
  4. Albert van der Horst

    Jorgen Grahn Guest

    Pretty much everyone use machines where octet, byte, uint8_t and char
    are the same thing modulo signedness. But when you're writing C code
    you have to acknowledge that it may be compiled for a machine where
    this isn't true ... or somehow make it clear that you don't intend to
    support exotic architectures.

    /Jorgen
     
    Jorgen Grahn, Dec 29, 2013
    #24
  5. Albert van der Horst

    Ian Collins Guest

    Well uint8_t will be consistent (if present), so you may as well use it.
     
    Ian Collins, Dec 29, 2013
    #25
  6. Albert van der Horst

    Jorgen Grahn Guest

    I get four warnings when compiling it (also on Debian stable, good
    choice by the way) and one hint from valgrind when it segfaults.
    (Valgrind doesn't give more information than a core dump would have in
    this case though.)
    Use the few troubleshooting tools which are available to you; it frees
    up your brain for more important tasks.


    sun.c:38:15: warning: unused parameter 'argv'

    You have reversed the meanings of argv and argc -- "v" is for "vector"
    and "c" is for "count". Not a bug, but unusual and confusing!
    sun.c:40:9: warning: unused variable 'i'
    sun.c:41:5: warning: implicit declaration of function 'atoi'
    sun.c:42:5: warning: format '%d' expects argument of type 'int', but
    argument 2 has type 'long int'
    /Jorgen
     
    Jorgen Grahn, Dec 29, 2013
    #26
  7. Albert van der Horst

    Jorgen Grahn Guest

    Two observations of mine:
    - The fresher the novice, the more elaborate comment blocks.
    - The more elaborate the comment block, the less useful its content.

    /Jorgen
     
    Jorgen Grahn, Dec 29, 2013
    #27
  8. Albert van der Horst

    David Brown Guest

    Nah, why clutter up the program with extra lines and #error directives
    for a situation that almost certainly will not occur? Just use
    "uint8_t" and let the compiler give an error that is marginally harder
    to understand if you have a platform without 8-bit support.

    Alternatively, use uint_least8_t, which will exist.

    It seems to me that using "uint8_t" directly is more appropriate than a
    macro /or/ a typedef. If you want to use a new type name here, then a
    typedef to an appropriate name (such as "typedef uint8_t flag_t;") would
    be more useful.
     
    David Brown, Dec 29, 2013
    #28
  9. Albert van der Horst

    David Brown Guest

    I have used processors with 16-bit "char", and no way to make an 8-bit
    type (except as a bitfield). Nowhere, in any of the documentation,
    manuals, datasheets, or anywhere else was there any reference to a
    "byte" that is not 8 bits. It made clear that a /char/ was 16 bits
    rather than the usual 8 bits, but they were never called "bytes".

    I haven't used such devices much - but the vast majority of people who
    use the term "byte" have never even heard of such devices, never mind
    used them.

    There are only two situations when "byte" does not automatically and
    unequivocally mean "8 bits" - one is in reference to ancient computer
    history (and documents from that era, such as network RFC's), and the
    other is extreme pedantry. There is a time and place for both of these
    - but you won't convince many people that you would ever /really/ think
    a reference to a "byte" meant anything other than 8 bits.

    (If you can give modern, or at least still-current, references to usage
    of "byte" for something other than 8 bits, then I will recant and blame
    the egg nog!.)

    A "char", as you say, has a well defined meaning - but not a well
    defined size.
     
    David Brown, Dec 29, 2013
    #29
  10. Albert van der Horst

    James Kuyper Guest

    On 12/29/2013 09:14 AM, David Brown wrote:
    ....
    Why should it be so hard to convince people of that? I can imagine
    having a hard time convincing people that "byte" means anything other
    than 8 bits (obviously, that only applies to people who don't consider
    the C standard authoritative) - however, why should it be difficult to
    convince other people that *I* believe it to be true?
     
    James Kuyper, Dec 29, 2013
    #30
  11. Albert van der Horst

    osmium Guest

    A byte that is not 8 bits is indeed rare, but I am certain there has been
    such usage in a more or less valid way. The 9-bit chunk on a Univac 11000
    series for example. I note you stuck "modern" in there as a qualifier. To
    refer to that system as a Unisys whatever (to modernize it), just obfuscates
    things. This thread has a lot more to do with pedants inheriting the earth
    than anything else. Or at least co.law.co.

    In a similar vein, anyone who spells that hard rive thingy as a disc instead
    of a disk is late to the party as far as I am concerned.
     
    osmium, Dec 29, 2013
    #31
  12. Albert van der Horst

    osmium Guest

    c.l.c. Damn!
     
    osmium, Dec 29, 2013
    #32
  13. Albert van der Horst

    Phil Carmody Guest

    I've thought various things along those lines in the past, but your
    rendering of the concept is absolutely perfect!

    Were there a list of C koans, that should be part of it.

    Phil
     
    Phil Carmody, Dec 29, 2013
    #33
  14. Albert van der Horst

    Phil Carmody Guest

    Kinda-piggybacking, OP not visible to me.

    The brain might be the perfect tool for the job. A bug in the code jumped
    out quicker than it would have taken me to copy/paste, compile, and run
    under gdb.


    BANG!!! i*i will be negative at some point.
    A wild stab in the dark, some point around i=46349.

    Possible solutions:
    (1) Generally - Use unsigned integer types for things you know can never
    be negative. (but take care to make sure those assumptions don't mess
    things up, loops that count down can often cause newbs problems.)
    (2) This particular case - Stop the sieving loop as soon as you're sure
    that no more composites can be sieved out. So don't loop i up to n, loop
    op to sqrt(n) instead, and then just dump the rest of the contents out
    in a trivial loop without sieving.

    Phil
     
    Phil Carmody, Dec 29, 2013
    #34
  15. Albert van der Horst

    Paul Guest

    Disc is used for optical media.
    Disk is used for hard drives.

    http://en.wikipedia.org/wiki/Disc

    Magnetic disk
    http://en.wikipedia.org/wiki/Disk_drive
    "The choice... is frequently historical,
    as in... "IBM 350 disk storage unit"."

    Optical disc (i.e. discus/frisbee)
    http://en.wikipedia.org/wiki/Frisbee
    http://en.wikipedia.org/wiki/Discus

    Paul
     
    Paul, Dec 29, 2013
    #35
  16. Albert van der Horst

    osmium Guest

    My mind set when I made my post. Disc is the proper US spelling for a disc,
    say a Frisbee. But someone in IBM spelled it disk and it stuck so all
    computer people should spell it disk. After all, IBM can do no wrong.

    I just tried to verify what I thought I knew and the first response from
    google for disc is disk! I don't think I have any paper dictionaries any
    more but drilling down in google seems to verify my earlier thoughts. Google
    was just "helping" me.
     
    osmium, Dec 29, 2013
    #36
  17. Albert van der Horst

    David Brown Guest

    It's a matter of believability. Certainly some people believe in things
    that others find unlikely, which is fair enough. But if you were to say
    "I believe the moon is made of cheese", I would not believe that you
    believe that. Obviously sticking to old-fashioned definitions of a term
    like "byte" isn't quite that extreme - but if you say, without reference
    or additional qualification, that you believe a reference to a "byte" in
    current writing might reasonably refer to something other than 8 bits,
    then I would not take you literally. I would assume you are
    exaggerating, joking, playing the devil's advocate, or otherwise trying
    to make a point in some way, or perhaps you have misread the question or
    mistyped the answer. (But I certainly won't assume you are lying or
    "trolling".) If you repeat your belief, I'll accept it - but until I
    was sure, I'd assume there was some other explanation.

    But I think this is getting a bit too philosophical - I'm off to watch
    Mr. Bean's New Year :)
     
    David Brown, Dec 29, 2013
    #37
  18. Albert van der Horst

    Jorgen Grahn Guest

    For me it's a matter of clarity. If there is a discussion and there's
    a hidden assumption that a char is eight bits, which other assumptions
    are there? The C standard is a help in this respect -- even though it
    sometimes forces you to consider some rare special cases.
    Do you by chance have a Windows background? Mine is Unix. There it's
    normal to try to write portable code, since there are so many
    different processors in use, and you never know where your program
    will end up running. Alignment restrictions, endianness, padding,
    sizeof long ... those things change all the time[1].

    That doesn't mean I always write portable code, or even document when
    I don't. Not even when I break the subset of C determined by POSIX ...
    but it's still my goal.

    /Jorgen

    [1] Not the CHAR_BIT aspect, though. IIRC POSIX requires an
    architecture with 8-bit bytes.
     
    Jorgen Grahn, Dec 29, 2013
    #38
  19. Albert van der Horst

    James Kuyper Guest

    On 12/29/2013 03:32 PM, David Brown wrote:
    ....
    I'm curious about your labeling of this definition as "old-fashioned". A
    very large fraction of newly written C code is targeted to embedded
    systems. I'm not sure how large that fraction is, but it's large enough
    that, on one memorable occasion, I had considerable trouble convincing
    one guy that it was less than 100%. Many of those embedded systems are
    DSPs with 16 bit bytes. So implementations of C with bytes that are not
    equivalent to octets is a very current issue.
    So, you consider the definition of "byte" that is provided by the C
    standard to be so thoroughly esoteric (is that the right word to cover
    your objection?) that it would never occur to you that I might consider
    that definition to be authoritative in the context of C code? Unless I
    emphatically told you otherwise (as I am now doing), you:
    That seems like a rather extreme position to take. It's as if you were
    actively resisting learning the fact (and it IS a fact) that there are
    contexts where some people use the term with a different definition from
    the one you're used to.
     
    James Kuyper, Dec 29, 2013
    #39
  20. But don't compute sqrt(n) each time through the loop. Computing sqrt(n)
    can be moderately expensive, and is likely to swamp the time you save by
    doing fewer iterations. Either compute sqrt(n) once at the top of the
    loop and save it in a variable (and watch out for floating-point
    rounding issues), or change the logic so you compare i*i vs. n rather
    than comparing i vs. sqrt(n).
     
    Keith Thompson, Dec 30, 2013
    #40
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.