Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #126878 > unrolled thread

C Construction Problem

Back to article view | Back to comp.lang.c

Contents

  C Construction Problem "F. Russell" <fr@random.info> - 2018-02-20 13:51 +0000
    Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-20 14:42 +0000
      Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-20 15:06 +0000
        Re: C Construction Problem Manfred <noname@invalid.add> - 2018-02-20 18:07 +0100
    Re: C Construction Problem Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-20 14:54 +0000
    Re: C Construction Problem "James R. Kuyper" <jameskuyper@verizon.net> - 2018-02-20 10:06 -0500
      Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-20 16:11 +0000
    Re: C Construction Problem Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-20 15:08 +0000
      Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-20 16:22 +0000
        Re: C Construction Problem Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-20 17:03 +0000
          Re: C Construction Problem Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-20 09:23 -0800
          Re: C Construction Problem Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-20 11:11 -0700
          Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-20 18:30 +0000
            Re: C Construction Problem Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-20 23:37 +0000
              Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-21 00:45 +0000
                Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-21 01:46 +0000
                  Re: C Construction Problem David Brown <david.brown@hesbynett.no> - 2018-02-21 08:49 +0100
                    Re: C Construction Problem Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-21 09:29 +0000
                      [OT] Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-21 11:24 +0000
                        Re: [OT] Re: C Construction Problem Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-21 14:41 +0300
                        Re: [OT] Re: C Construction Problem David Brown <david.brown@hesbynett.no> - 2018-02-21 15:10 +0100
                        Re: [OT] Re: C Construction Problem Robert Wessel <robertwessel2@yahoo.com> - 2018-02-21 12:36 -0600
                          Re: [OT] Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-21 21:04 +0000
                            Re: [OT] Re: C Construction Problem Robert Wessel <robertwessel2@yahoo.com> - 2018-02-21 18:20 -0600
                  Re: C Construction Problem Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-21 11:09 +0300
                  Re: C Construction Problem Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-21 02:29 -0800
                  Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-21 11:32 +0000
                  Re: C Construction Problem Geoff <geoff@invalid.invalid> - 2018-02-26 11:02 -0800
                    Re: C Construction Problem David Brown <david.brown@hesbynett.no> - 2018-02-27 09:22 +0100
                      Re: C Construction Problem Geoff <geoff@invalid.invalid> - 2018-02-27 11:18 -0800
                        Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-27 19:51 +0000
                          Re: C Construction Problem Robert Wessel <robertwessel2@yahoo.com> - 2018-02-28 01:54 -0600
                        Re: C Construction Problem Robert Wessel <robertwessel2@yahoo.com> - 2018-02-28 01:43 -0600
                          Re: C Construction Problem Geoff <geoff@invalid.invalid> - 2018-02-28 12:54 -0800
                    Re: archive decompressor Noob <root@127.0.0.1> - 2018-03-04 12:34 +0100
                Re: C Construction Problem Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-21 11:04 +0300
                  Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-21 11:27 +0000
                    Re: C Construction Problem Anton Shepelev <anton.txt@gmail.com> - 2018-02-28 22:59 +0300
                  Re: C Construction Problem supercat@casperkitty.com - 2018-02-21 08:49 -0800
              Re: C Construction Problem Geoff <geoff@invalid.invalid> - 2018-02-26 11:08 -0800
                Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-26 23:51 +0000
                  Re: C Construction Problem Geoff <geoff@invalid.invalid> - 2018-02-27 11:24 -0800
            Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 08:07 -0800
              Re: C Construction Problem fr314159@gmail.com - 2018-02-21 09:16 -0800
                Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 21:26 -0800
              Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-21 09:43 -0800
                Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 22:47 -0800
                  Re: C Construction Problem Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-22 13:09 +0000
                    Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-24 13:37 -0800
                  Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-22 10:50 -0800
                    Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-24 13:58 -0800
                      Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-24 15:05 -0800
                        Re: C Construction Problem Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-25 03:21 -0800
                          Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-25 11:51 +0000
                            Re: C Construction Problem Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-25 04:06 -0800
                              Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-25 12:47 +0000
                              Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-25 13:20 +0000
                                Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-25 17:46 +0000
                                  Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-25 18:58 +0000
                                    Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-25 20:01 +0000
                                      Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-25 20:25 +0000
                                  Re: C Construction Problem Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-26 02:49 -0800
                              Re: C Construction Problem Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-25 20:02 +0000
                              Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-25 15:13 -0800
                          Re: C Construction Problem Robert Wessel <robertwessel2@yahoo.com> - 2018-02-25 11:50 -0600
                          Re: C Construction Problem Ian Collins <ian-news@hotmail.com> - 2018-02-26 07:38 +1300
                            Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-25 15:15 -0800
                            Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-26 22:02 -0800
                              Re: C Construction Problem jameskuyper@verizon.net - 2018-02-27 06:32 -0800
                                Re: C Construction Problem GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-27 16:56 +0100
                                  Re: C Construction Problem jameskuyper@verizon.net - 2018-02-27 08:27 -0800
                                    Re: C Construction Problem GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-27 18:02 +0100
                                      Re: C Construction Problem jameskuyper@verizon.net - 2018-02-27 10:23 -0800
                                        Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-03 01:09 -0800
                                      Re: C Construction Problem David Brown <david.brown@hesbynett.no> - 2018-02-28 10:37 +0100
                                    Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-03 01:29 -0800
                                      Re: C Construction Problem Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 02:00 -0800
                                Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-27 08:46 -0800
                                  Re: C Construction Problem jameskuyper@verizon.net - 2018-02-27 09:15 -0800
                                Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-03 02:08 -0800
                                  Re: C Construction Problem Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 02:31 -0800
                                  Re: C Construction Problem Ian Collins <ian-news@hotmail.com> - 2018-03-04 10:34 +1300
                                    Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-19 10:27 -0700
                                  Re: C Construction Problem jameskuyper@verizon.net - 2018-03-03 21:35 -0800
                                    Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-17 10:29 -0700
                                      Re: C Construction Problem Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-18 08:14 -0700
                          Re: C Construction Problem David Brown <david.brown@hesbynett.no> - 2018-02-25 21:49 +0100
                          Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-25 15:09 -0800
                          Re: C Construction Problem gazelle@shell.xmission.com (Kenny McCormack) - 2018-02-26 13:46 +0000
                            Re: C Construction Problem David Brown <david.brown@hesbynett.no> - 2018-02-26 14:57 +0100
                        Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-26 22:14 -0800
              Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-22 00:11 +0000
                Re: C Construction Problem Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-21 17:27 -0700
      Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-20 09:30 -0800
        Re: C Construction Problem Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-21 00:23 +0000
    Re: C Construction Problem Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-20 09:11 -0700
      Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-20 16:38 +0000
        Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-20 17:07 +0000
        Re: C Construction Problem John Bode <jfbode1029@gmail.com> - 2018-02-20 09:09 -0800
        Re: C Construction Problem "James R. Kuyper" <jameskuyper@verizon.net> - 2018-02-20 12:18 -0500
          Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-20 09:38 -0800
        Re: C Construction Problem Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-20 11:08 -0700
        Re: C Construction Problem Gordon Burditt <gordon@hammy.burditt.org> - 2018-02-20 21:47 -0600
          Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-21 09:36 -0800
            Re: C Construction Problem Geoff <geoff@invalid.invalid> - 2018-02-26 11:21 -0800

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

#127107

On Mon, 26 Feb 2018 11:08:02 -0800, Geoff wrote:

>
> When printing to gray scale
> for print publication the image dots can be aliased by resampling,
> thus creating moire patterns. This is the issue the cited pei code is
> supposed to remedy.
>

That's not actually correct.

The issue here is the scanning of already printed material,
such as illustrations or photographs in books or magazines.
These illustrations are produced by a "halftone" process wherein
shades of grey are reproduced either by varying the printing dot
size or dot density.  For example, looking at a newspaper illustration
with a magnifying glass will reveal the halftone pattern.

The scanning of printed material at high resolution will capture
these halftone dot patterns as a noise artifact.  The PEI software
attempts to remove this noise through a technique known as
digital convolution.

[toc] | [prev] | [next] | [standalone]

#127143

On 26 Feb 2018 23:51:24 GMT, "F. Russell" <fr@random.info> wrote:

>On Mon, 26 Feb 2018 11:08:02 -0800, Geoff wrote:
>
>>
>> When printing to gray scale
>> for print publication the image dots can be aliased by resampling,
>> thus creating moire patterns. This is the issue the cited pei code is
>> supposed to remedy.
>>
>
>That's not actually correct.
>
>The issue here is the scanning of already printed material,
>such as illustrations or photographs in books or magazines.
>These illustrations are produced by a "halftone" process wherein
>shades of grey are reproduced either by varying the printing dot
>size or dot density.  For example, looking at a newspaper illustration
>with a magnifying glass will reveal the halftone pattern.
>
>The scanning of printed material at high resolution will capture
>these halftone dot patterns as a noise artifact.  The PEI software
>attempts to remove this noise through a technique known as
>digital convolution.

That's not what the peiHalfTone.pdf stated. It was describing
sub-sampling artifacts of existing files. It makes no mention of
scanning printed matter, only that the input files are TIFF files.

[toc] | [prev] | [next] | [standalone]

#126930

"F. Russell" <fr@random.info> writes:

> On Tue, 20 Feb 2018 17:03:28 +0000, Ben Bacarisse wrote:
>
>> IOW, my inclination would be to make the code portable rather than
>> convert it to 64-bits.
>
> I doubt if many others would be interested in using the code,
> but to make it truly portable would require a lot of other
> changes as well.  For one thing, it would need to be rewritten
> to use the latest libtiff versions.  Currently it will only
> compile using a very old version of libtiff.
>
> My goal has only been to make it run on a pure 64-bit
> system.  Although I have not checked, the code would probably
> function on hybrid 32/64-bit systems such as a multi-lib Linux.

I downloaded the code and got it to compile.  Here are some
recommendations resulting from that.

(1) The code is compiled using gcc in its default mode.  Don't Do
That.  I recommend 'gcc -std=c99 -pedantic-errors', or similar.
I recommend against -std=c90 (or the various equivalents to
that).

(2) The code has a dozen or so functions defined with no return
type.  Don't Do That.  The main() functions should be int main(),
and there are two help() functions that should be void help().

(3) There are about 20 functions that are called without a prior
declaration (presumably taking advantage of C90's implicit
function declaration rule).  Don't Do That.  What I did was just
put declarations for all of them in pei.h.  (Full list given
below.)  To be clear, that isn't a recommendation for what you
should do to declare those functions, but one way or another make
sure the functions are declared before being called.

(4) In pei.h there are several type names defined using #define.
Don't Do That.  Use typedef instead.

(5) In fact many of those types are in the tiff library headers.
The link you posted didn't have the tiff (or jpeg) stuff, so
I installed the standard packages.  After doing that the big
block of type definitions in pei.h can be just this:

    #include <tiff.h>
    typedef float float32;
    typedef double float64;

(6) There were some names needed from tiff that weren't there
in the current tiff package.  To get the code to compile (but
no run test), I put these two lines in pei.h:

    typedef TIFFHeaderClassic TIFFHeader;
    typedef struct { int foo; } TIFFDirEntry;

Obviously you should look into that more thoroughly, but
doing this did get me to the point of building executables.

And yes I do recommend switching to later, standard, tiff
and jpeg libraries.  I haven't run anything but everything
builds without problem.  (A -ltiff is still needed, but
I just removed the -I$(TIFFDIR) and -L$(TIFFDIR) from the
Makefile.  Similarly for jpeg, except I don't know if -ljpeg is
needed.)

(7) There are several system functions called without having
done a #include for the requisite header.  For the sake of
expediency I simply added several #include's to pei.h.  Here
is that list:

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

(8) In a couple of places there were printf() conversions that
didn't match up with the argument types.  I think all of those
were the result of trying to print a pointer type as some integer
type.  I recommend using %p, or perhaps something else if %p
cannot be used for some reason.

(9) In a couple of places there were calls to GETPARAMETER() that
looked like this example:

    GETPARAMETER(hex?"%x":"%d",t);

I got diagnostics trying to compile these.  The problem is that
the %x specification expects an address-of-unsigned argument, and
the %d specification expects an address-of-signed argument.
Until a better way is found, maybe this is better (still ugly,
but at least the ugliness is immediately apparent):

    if(hex){GETPARAMETER("%x",*(unsigned*)&t);}else{GETPARAMETER("%d",t);}

(10) In peiConvolve.c there are two batches of four lines/batch
that look like this

    CONVOLVE(int8,int8,uint8,SCALESI,0,255,PIXSUM,NORM);

that I think should have the constants adjusted as follows:

    CONVOLVE(int8,int8,uint8,SCALESI,-128,127,PIXSUM,NORM);

What I can say for sure is the first way gives a diagnostic, and
the second way does not.

(11) For the macros involving imageType member access, many of
these occur in Get/Set pairs, eg:

    #define peiGetOps(image)          (((imageType*)(image))->ops)

    #define peiSetOps(image,p)        ((imageType*)(image))->ops=(p)

These definitions aren't as factored as they could be.  In this
case for example the peiSetOps() macro could be defined in terms
of peiGetOps().  But having two macros is already overkill for
things like this.  I recommend instead defining only one macro
per pair, like so:

    #define peiOps(image)          (((imageType*)(image))->ops)

after which the code can use 'peiOps(image)' to get the value,
and 'peiOps(image) = new_value' to update the value.  Cases where
it really is important to have a separate interface to update
a value can do that of course (for which a function is very
likely better than a macro), but these simple cases don't
need them.

(12) The code commits a multitude of programming sins in the area
of casting, and converting/punning between pointers and integers.
Very much Not A Good Idea.  I think most of these problems
revolve around the use of the clientData member of the struct
type imageType.  All the uses of the clientData member are
wrapped up inside macros in the various .c files.  So, rather
than having a single member, for which the type would be fixed, I
recommend having several:

    unsigned long long  clientUnsigned[ .. suitable constant 1 ..  ];
             long long  clientSigned[   .. suitable constant 2 ..  ];
                double  clientDouble[   .. suitable constant 3 .. ];
                  void  *clientAddress[ .. suitable constant 4 .. ];

which allows the subsidiary macros in the .c files to be written
without using casting.  This change by itself goes a long way
towards making the program portable between 32-bit and 64-bit
environments.


Okay I'm stopping here.  There may have been something else I
wanted to mention but if so I don't remember what it is, and
besides having one more item on the list would be unlucky.  Does
all of the above make sense, or is there a point somewhere in
there that you want to ask about?

================

Here is the list of functions that needed declaring to avoid
diagnostics about being implicitly declared.  For the sake of
expediency I declared them using old-style declarations, but of
course in the program I recommend using prototypes for such
forward declarations.

    int peiLog();
    int cacheInitImage();
    int constInitImage();
    int convInitImage();
    int convertInitImage();
    int listInitImage();
    void longFill();
    void natWriteBinaryPixel();
    int nint();
    int peiCopyImage();
    int peiCopyPages();
    int peiInitInputImage();
    int peiLogPrint();
    int peiParseOutputFileOptions();
    void peiPrintOutputFileOptions();
    int peiRegion();
    int peiStats();
    int regionInitImage();
    int scalarInitImage();
    int tiffInitImage();

[toc] | [prev] | [next] | [standalone]

#126935

On Wednesday, February 21, 2018 at 11:07:46 AM UTC-5, Tim Rentsch wrote:

> 
> I downloaded the code and got it to compile.  Here are some
> recommendations resulting from that.
> 

Yes, the code will compile, but it won't successfully execute
on a pure 64-bit machine.

I appreciate that you've taken the time and trouble to
investigate the code.  Yes, there is a LOT of cleanup involved
but I was primarily interested in those (to me) strange
constructions.

I suspect that this software is some sort of preliminary design
that was made available publically for some unknown reason.

The software consists of several "pieces" that are executed
from a controlling CSH script.  Many temporary files are created
in the process.  A complete and finalized program would not
operate in this way.

But it now works well for me.

> 
> but
> doing this did get me to the point of building executables.
> 

But only some of those executables will run successfully.
IOW, an input image will not be successfully processed.

[toc] | [prev] | [next] | [standalone]

#126973

fr314159@gmail.com writes:

> On Wednesday, February 21, 2018 at 11:07:46 AM UTC-5, Tim Rentsch wrote:
>
>> I downloaded the code and got it to compile.  Here are some
>> recommendations resulting from that.
>
> Yes, the code will compile, but it won't successfully execute
> on a pure 64-bit machine.

The point of getting the code to compile was only to help
investigate what it would take to solve the 32-versus-64
problem.  I never imagined merely getting the code to compile
would mean it would work in my environment.  I thought some
of my other statements made that clear.  In any case you are
perfectly free to ignore my comments or suggestions if that
is what you want to do.

[toc] | [prev] | [next] | [standalone]

#126937

Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
> (1) The code is compiled using gcc in its default mode.  Don't Do
> That.  I recommend 'gcc -std=c99 -pedantic-errors', or similar.
> I recommend against -std=c90 (or the various equivalents to
> that).

Why not -std=c11?

> (2) The code has a dozen or so functions defined with no return
> type.  Don't Do That.  The main() functions should be int main(),
> and there are two help() functions that should be void help().

Better, they should be int main(void) and void help(void),
respectively.  In particular, the latter lets the compiler diagnose
incorrect calls to help() with extra arguments.

[...]

> (8) In a couple of places there were printf() conversions that
> didn't match up with the argument types.  I think all of those
> were the result of trying to print a pointer type as some integer
> type.  I recommend using %p, or perhaps something else if %p
> cannot be used for some reason.

And if you use %p, you should cast the corresponding argument to void*.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#126976

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
> [...]
>
>> (1) The code is compiled using gcc in its default mode.  Don't Do
>> That.  I recommend 'gcc -std=c99 -pedantic-errors', or similar.
>> I recommend against -std=c90 (or the various equivalents to
>> that).
>
> Why not -std=c11?

There's a big difference between C90 and C99, but not so much
between C99 and C11.  Unless there is a particular reason for
wanting to use C11, I think the more conservative choice is
better.  Looking over the list of major changes given in N1570,
I don't see any that add significant value for this program (or
even most other programs).  As I see it the question here is not
"why not C11?" but "what need is compelling enough to prompt a
change to C11?".  Until there is one, it's better to stay put.

>> (2) The code has a dozen or so functions defined with no return
>> type.  Don't Do That.  The main() functions should be int main(),
>> and there are two help() functions that should be void help().
>
> Better, they should be int main(void) and void help(void),
> respectively.  In particular, the latter lets the compiler diagnose
> incorrect calls to help() with extra arguments.

My comment was only about the return types.  I'm in the habit of
writing () after function names just to indicate they are
functions.  I deliberately left out the parameters for main(),
which the various main()'s in this code have.  I mentioned using
prototypes in another part of the posting.

>> (8) In a couple of places there were printf() conversions that
>> didn't match up with the argument types.  I think all of those
>> were the result of trying to print a pointer type as some integer
>> type.  I recommend using %p, or perhaps something else if %p
>> cannot be used for some reason.
>
> And if you use %p, you should cast the corresponding argument to void*.

BEEP!  Bad advice.  Casting should be avoided as much as possible
and this case is no exception.  To get a pointer into a suitable
type for %p, it should be converted, not cast:

    (void*){ some_pointer }

[toc] | [prev] | [next] | [standalone]

#126987

On Thu, 2018-02-22, Tim Rentsch wrote:
> Keith Thompson <kst-u@mib.org> writes:
>
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> [...]
>>
>>> (1) The code is compiled using gcc in its default mode.  Don't Do
>>> That.  I recommend 'gcc -std=c99 -pedantic-errors', or similar.
>>> I recommend against -std=c90 (or the various equivalents to
>>> that).
>>
>> Why not -std=c11?
>
> There's a big difference between C90 and C99, but not so much
> between C99 and C11.  Unless there is a particular reason for
> wanting to use C11, I think the more conservative choice is
> better.  Looking over the list of major changes given in N1570,
> I don't see any that add significant value for this program (or
> even most other programs).  As I see it the question here is not
> "why not C11?" but "what need is compelling enough to prompt a
> change to C11?".  Until there is one, it's better to stay put.

Or, if it had been me arguing for -std=c99, it would be because I have
simply not learned much about C11 yet.  Except that it has a static
assert construct.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#127021

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> On Thu, 2018-02-22, Tim Rentsch wrote:
>
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> [...]
>>>
>>>> (1) The code is compiled using gcc in its default mode.  Don't Do
>>>> That.  I recommend 'gcc -std=c99 -pedantic-errors', or similar.
>>>> I recommend against -std=c90 (or the various equivalents to
>>>> that).
>>>
>>> Why not -std=c11?
>>
>> There's a big difference between C90 and C99, but not so much
>> between C99 and C11.  Unless there is a particular reason for
>> wanting to use C11, I think the more conservative choice is
>> better.  Looking over the list of major changes given in N1570,
>> I don't see any that add significant value for this program (or
>> even most other programs).  As I see it the question here is not
>> "why not C11?" but "what need is compelling enough to prompt a
>> change to C11?".  Until there is one, it's better to stay put.
>
> Or, if it had been me arguing for -std=c99, it would be because I have
> simply not learned much about C11 yet.  Except that it has a static
> assert construct.

Interesting statement.  I think I was tacitly saying something
similar under the "more conservative choice" umbrella, but it's
probably worth making that a bit more explicit.  Thank you for
making the comment.

[toc] | [prev] | [next] | [standalone]

#126992

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> [...]
>>> (1) The code is compiled using gcc in its default mode.  Don't Do
>>> That.  I recommend 'gcc -std=c99 -pedantic-errors', or similar.
>>> I recommend against -std=c90 (or the various equivalents to
>>> that).
>>
>> Why not -std=c11?
>
> There's a big difference between C90 and C99, but not so much
> between C99 and C11.  Unless there is a particular reason for
> wanting to use C11, I think the more conservative choice is
> better.  Looking over the list of major changes given in N1570,
> I don't see any that add significant value for this program (or
> even most other programs).  As I see it the question here is not
> "why not C11?" but "what need is compelling enough to prompt a
> change to C11?".  Until there is one, it's better to stay put.

My own preference is to use the current standard unless there's a good
reason not to.  gcc support for C11 is now about as good as its support
for C99.

[...]
        
>> And if you use %p, you should cast the corresponding argument to void*.
>
> BEEP!  Bad advice.  Casting should be avoided as much as possible
> and this case is no exception.  To get a pointer into a suitable
> type for %p, it should be converted, not cast:
>
>     (void*){ some_pointer }

So rather than a cast
    printf("%p\n", (void*)some_pointer);
you'd use a compound literal with exactly the same semantics?
    printf("%p\n", (void*){ some_pointer });

I've never seen that, and it would never have occurred to me.  After
considering it, I'd still use the cast.

An advantage of the compound literal is that it relies on the implicit
conversion, so it will fail to compile if the expression isn't one that
can be implicitly converted to void*.  In my opinion, that's not enough
of an advantage to justify it.

I agree that casting should almost always be avoided.  Arguments to
variadic functions are one of the rare cases where I consider them
appropriate.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#127023

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> [...]
>>>
>>>> (1) The code is compiled using gcc in its default mode.  Don't Do
>>>> That.  I recommend 'gcc -std=c99 -pedantic-errors', or similar.
>>>> I recommend against -std=c90 (or the various equivalents to
>>>> that).
>>>
>>> Why not -std=c11?
>>
>> There's a big difference between C90 and C99, but not so much
>> between C99 and C11.  Unless there is a particular reason for
>> wanting to use C11, I think the more conservative choice is
>> better.  Looking over the list of major changes given in N1570,
>> I don't see any that add significant value for this program (or
>> even most other programs).  As I see it the question here is not
>> "why not C11?" but "what need is compelling enough to prompt a
>> change to C11?".  Until there is one, it's better to stay put.
>
> My own preference is to use the current standard unless there's a good
> reason not to.  [...]

Do you have some reasoning to offer that might explain this bias?
Or do you think of it as just axiomatic?

>>> And if you use %p, you should cast the corresponding argument to void*.
>>
>> BEEP!  Bad advice.  Casting should be avoided as much as possible
>> and this case is no exception.  To get a pointer into a suitable
>> type for %p, it should be converted, not cast:
>>
>>     (void*){ some_pointer }
>
> So rather than a cast
>     printf("%p\n", (void*)some_pointer);
> you'd use a compound literal with exactly the same semantics?
>     printf("%p\n", (void*){ some_pointer });
>
> I've never seen that, and it would never have occurred to me.  After
> considering it, I'd still use the cast.
>
> An advantage of the compound literal is that it relies on the implicit
> conversion, so it will fail to compile if the expression isn't one that
> can be implicitly converted to void*.  In my opinion, that's not enough
> of an advantage to justify it.
>
> I agree that casting should almost always be avoided.  Arguments to
> variadic functions are one of the rare cases where I consider them
> appropriate.

I'm mystified by your reasoning here.  You point out an advantage
for using a compound literal.  You don't point out any advantages
for using a cast.  If we're going to be using C99 or later then
ISTM that cast choice is all downside with no upside.  Or is what
you're saying something akin to "we should keep doing things the
older, riskier way because that's what people are used to"?
What's the point of switching to a more current standard if you
carry over all the old bad habits from the earlier standards?

[toc] | [prev] | [next] | [standalone]

#127025

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> My own preference is to use the current standard unless there's a good
>> reason not to.  [...]
>
> Do you have some reasoning to offer that might explain this bias?
> Or do you think of it as just axiomatic?

Any attempt to explain my preference would likely lead to a debate that
I'm not interested in having.

[...]

>> So rather than a cast
>>     printf("%p\n", (void*)some_pointer);
>> you'd use a compound literal with exactly the same semantics?
>>     printf("%p\n", (void*){ some_pointer });
>>
>> I've never seen that, and it would never have occurred to me.  After
>> considering it, I'd still use the cast.
>>
>> An advantage of the compound literal is that it relies on the implicit
>> conversion, so it will fail to compile if the expression isn't one that
>> can be implicitly converted to void*.  In my opinion, that's not enough
>> of an advantage to justify it.
>>
>> I agree that casting should almost always be avoided.  Arguments to
>> variadic functions are one of the rare cases where I consider them
>> appropriate.
>
> I'm mystified by your reasoning here.  You point out an advantage
> for using a compound literal.  You don't point out any advantages
> for using a cast.  If we're going to be using C99 or later then
> ISTM that cast choice is all downside with no upside.  Or is what
> you're saying something akin to "we should keep doing things the
> older, riskier way because that's what people are used to"?
> What's the point of switching to a more current standard if you
> carry over all the old bad habits from the earlier standards?

The compound literal form is in my opinion relatively obscure,
and likely to be confusing to many readers.  I rarely use or see
compound literals, and when I do they're usually for aggregate types.
(No doubt that's largely the result of inertia.)  And the need
to compile with a C90 compiler is rare these days, but not yet
entirely nonexistent.

Using a compound literal in this context is an interesting idea,
and one that I hadn't encountered before.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#127029

On Saturday, February 24, 2018 at 11:06:12 PM UTC, Keith Thompson wrote:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
> > Keith Thompson <kst-u@mib.org> writes:
> [...]
> >> My own preference is to use the current standard unless there's a good
> >> reason not to.  [...]
> >
> > Do you have some reasoning to offer that might explain this bias?
> > Or do you think of it as just axiomatic?
> 
> Any attempt to explain my preference would likely lead to a debate that
> I'm not interested in having.
> 
The main reason for sticking to C89 is that Microsoft doesn't support
the more recent standards. But now C89 support in Visual Studio is
going to be removed too.

[toc] | [prev] | [next] | [standalone]

#127030

On 25/02/2018 11:21, Malcolm McLean wrote:
> On Saturday, February 24, 2018 at 11:06:12 PM UTC, Keith Thompson wrote:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>> [...]
>>>> My own preference is to use the current standard unless there's a good
>>>> reason not to.  [...]
>>>
>>> Do you have some reasoning to offer that might explain this bias?
>>> Or do you think of it as just axiomatic?
>>
>> Any attempt to explain my preference would likely lead to a debate that
>> I'm not interested in having.
>>
> The main reason for sticking to C89 is that Microsoft doesn't support
> the more recent standards. But now C89 support in Visual Studio is
> going to be removed too.
> 

How does that work? Some old features will be deprecated?

(Since I now have MSVC working, I tried it on some of my C sources to 
see how fast it was. But it couldn't cope with some of my string 
constants which it said were too long, which I thought extraordinary 
given the scale of this compiler and its IDE.

No other compiler had a problem.

The docs for VS2015 say individual strings can be 2K, but can be 
concatenated up to 64K. My longest single string was 35K. How about 
that, a 16-bit 64KB limit on a compiler system that is a 6000000KB 
download, running on a machine with 8000000KB of RAM.

Maybe there was no room left for data...)

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#127033

On Sunday, February 25, 2018 at 11:51:15 AM UTC, Bart wrote:
> On 25/02/2018 11:21, Malcolm McLean wrote:
> > On Saturday, February 24, 2018 at 11:06:12 PM UTC, Keith Thompson wrote:
> >> Tim Rentsch <txr@alumni.caltech.edu> writes:
> >>> Keith Thompson <kst-u@mib.org> writes:
> >> [...]
> >>>> My own preference is to use the current standard unless there's a good
> >>>> reason not to.  [...]
> >>>
> >>> Do you have some reasoning to offer that might explain this bias?
> >>> Or do you think of it as just axiomatic?
> >>
> >> Any attempt to explain my preference would likely lead to a debate that
> >> I'm not interested in having.
> >>
> > The main reason for sticking to C89 is that Microsoft doesn't support
> > the more recent standards. But now C89 support in Visual Studio is
> > going to be removed too.
> > 
> 
> How does that work? Some old features will be deprecated?
> 
> (Since I now have MSVC working, I tried it on some of my C sources to 
> see how fast it was. But it couldn't cope with some of my string 
> constants which it said were too long, which I thought extraordinary 
> given the scale of this compiler and its IDE.
> 
> No other compiler had a problem.
> 
> The docs for VS2015 say individual strings can be 2K, but can be 
> concatenated up to 64K. My longest single string was 35K. How about 
> that, a 16-bit 64KB limit on a compiler system that is a 6000000KB 
> download, running on a machine with 8000000KB of RAM.
> 
> Maybe there was no room left for data...)
> 
You'd think they'd use a 32 bit integer to hold the string length,
in this day and age. (As a bioinformatician, I use some very long
strings to represent DNA sequences).

The standard library is already deprecated. It transpires that it
is now listed for total removal. I'm not quite sure what the plan
is for the C compiler, but basically it is going.

Which is depressing. It makes all my work porting Baby X to Windows
worthless.

[toc] | [prev] | [next] | [standalone]

#127035

On 25/02/2018 12:06, Malcolm McLean wrote:
> On Sunday, February 25, 2018 at 11:51:15 AM UTC, Bart wrote:
>> On 25/02/2018 11:21, Malcolm McLean wrote:

>> How does that work? Some old features will be deprecated?

> The standard library is already deprecated. It transpires that it
> is now listed for total removal. I'm not quite sure what the plan
> is for the C compiler, but basically it is going.
> 
> Which is depressing. It makes all my work porting Baby X to Windows
> worthless.

There are other C compilers for Windows (loads actually). And I doubt 
that MS are going to make changes to MSVC so that it can no longer 
compile programs using its Win32 API.

I have an old copy of BBX and managed to compile and run your test 
program with MSVC (of VS2017), lccwin32 and gcc. Although I needed to 
change GWL_USERDATA to GWLP_USERDATA for a 64-bit build.

(On other compilers, there was a problem with windowsx.h and 
GET_X_LPARAM, and there were pointer conversion issues warnings and 
other minor matters.)

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#127037

On Sun, 25 Feb 2018 04:06:31 -0800, Malcolm McLean wrote:

> As a bioinformatician, I use some very long
> strings to represent DNA sequences.
> 

Why would you use STRINGS and not BIT FIELDS?

If I understand the situation correctly, with BIT FIELDS
the memory storage requirements could be reduced by
one quarter without adding too much extra processing
overhead.

I am just curious since I know little about bioinformatics
programming.

[toc] | [prev] | [next] | [standalone]

#127038

On 25/02/2018 13:20, F. Russell wrote:
> On Sun, 25 Feb 2018 04:06:31 -0800, Malcolm McLean wrote:
> 
>> As a bioinformatician, I use some very long
>> strings to represent DNA sequences.
>>
> 
> Why would you use STRINGS and not BIT FIELDS?

Because the language supports strings (as byte arrays) but not bit 
fields? At least not in a form that is useful for this purpose.

> If I understand the situation correctly, with BIT FIELDS
> the memory storage requirements could be reduced by
> one quarter without adding too much extra processing
> overhead.

If memory absolutely had to be kept to a minimum, then you can emulate 
the 2-bit arrays that are needed. But you have to create that.

(I've implemented 4-bit, 2-bit and 1-bit types and arrays, as a natural 
progression of 64, 32, 16 and 8-bit, but not in a static language like 
C. I believe it is feasible, although the bit-pointers that are needed 
will not be compatible with regular pointers, and there would be issues 
with 'sizeof'.

Although of course such types will never be built-in to C or C++ and 
have to be emulated in both cases. I don't know how hard that is in C++, 
or how effective, or whether it has already been done. 2-bit arrays are 
less common than one-bit ones.)

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#127041

On Sun, 25 Feb 2018 17:46:02 +0000, bartc wrote:

> 
> Because the language supports strings (as byte arrays) but not bit 
> fields? At least not in a form that is useful for this purpose.
> 

I was thinking of an array of the following struct:

struct {
   unsigned int codon00 : 2;
   unsigned int codon01 : 2;
   unsigned int codon02 : 2;
   unsigned int codon03 : 2;
   unsigned int codon04 : 2;
   unsigned int codon05 : 2;
   unsigned int codon06 : 2;
   unsigned int codon07 : 2;
   unsigned int codon08 : 2;
   unsigned int codon09 : 2;
   unsigned int codon10 : 2;
   unsigned int codon11 : 2;
   unsigned int codon12 : 2;
   unsigned int codon13 : 2;
   unsigned int codon14 : 2;
   unsigned int codon15 : 2;
} status;

There would be some computational overhead to translate
the ordinary index into the struct array index, but it
might be worthwhile.

[toc] | [prev] | [next] | [standalone]

#127042

On 25/02/2018 18:58, F. Russell wrote:
> On Sun, 25 Feb 2018 17:46:02 +0000, bartc wrote:
> 
>>
>> Because the language supports strings (as byte arrays) but not bit
>> fields? At least not in a form that is useful for this purpose.
>>
> 
> I was thinking of an array of the following struct:
> 
> struct {
>     unsigned int codon00 : 2;
>     unsigned int codon01 : 2;
>     unsigned int codon02 : 2;
>     unsigned int codon03 : 2;
>     unsigned int codon04 : 2;
>     unsigned int codon05 : 2;
>     unsigned int codon06 : 2;
>     unsigned int codon07 : 2;
>     unsigned int codon08 : 2;
>     unsigned int codon09 : 2;
>     unsigned int codon10 : 2;
>     unsigned int codon11 : 2;
>     unsigned int codon12 : 2;
>     unsigned int codon13 : 2;
>     unsigned int codon14 : 2;
>     unsigned int codon15 : 2;
> } status;
> 
> There would be some computational overhead to translate
> the ordinary index into the struct array index, but it
> might be worthwhile.

I don't know if using such a struct would be any better then just 
employing shifts and masks to extract a 2-bit element out of a normal 
byte array.

But I then coded something up to see what those masks would look like 
(see below) and perhaps it could do with some help after all.

Still, I believe this is usable via a getelem/setelem interface.

(As coded, it should deal with arrays up to 8 billion elements/2 billion 
bytes, unless you put size_t everywhere. How many will typically be 
needed in one array?)


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

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

typedef struct {unsigned char* data; int length,bytes;} Bit2array;

void abort(char* mess) {puts(mess); exit(1);}

int getelem(Bit2array* A, int index) {
     int x,y;
     if (index<0 || index>=A->length) abort("ge:bounds");
     x = index >> 2;          // byte index
     y = index & 3;           // index within byte

     if (y)
         return (A->data[x] >> (y*2)) & 3;
     else
         return (A->data[x] & 3);
}

void setelem(Bit2array* A, int index, int value) {
     int x,y, mask;
     if (index<0 || index>=A->length) abort("se:bounds");
     x = index >> 2;
     y = index & 3;
     value &= 3;
     mask = 3;

     if (y) {
         value <<= (y*2);
         mask  <<= (y*2);
     }
     A->data[x] = (A->data[x] & ~mask) | value;
}

Bit2array* createbit2(int length){
     Bit2array* A;
     A = malloc(sizeof(Bit2array));
     if (A == NULL) abort("mem1");
     A->bytes  = length/4+1;

     A->data   = malloc(A->bytes);
     if (A->data == NULL) abort("mem2");
     memset(A->data, 0, A->bytes);

     A->length = length;
     return A;
}

int main(void) {
     Bit2array* A;
     enum {N = 100000000};
     int i;

     A = createbit2(N);

     printf("A length = %d\n",A->length);
     printf("A sizeof = %d\n",A->bytes);

//	for (i=0; i<N; ++i) setelem(A,i,i);
//	for (i=0; i<N; ++i) printf("%d: %d\n", i,getelem(A,i));

}

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

-- 
bartc

[toc] | [prev] | [next] | [standalone]

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web