But DO C hackers code concisely? 
Author Message
 But DO C hackers code concisely?

We've heard a bit in this newsgroup recently about the wonders of C notation
and how concise it can be.  I find myself wondering whether real C code is in
fact concise.  There is no dispute that it CAN be.  What I wonder is whether
it IS.

Here's a real example taken from a book that I have found very helpful.
The book is about Windows support tools, not primarily about C coding.
Here's the first of two examples.

 1.     ltoa (((lBufIndex) * 16), buf, 16);
 2.     len = strlen (buf);

 3.     for (cnt = 6;
 4.        cnt > len;
 5.        cnt--)
 6.      {
 7.      for (shift = 6;
 8.         shift > 0;
 9.         shift--)
10.        * (buf + shift) = * (buf + shift - 1);
11.      * buf = '0';
12.      }
13.     for (cnt = 0;
14.        cnt < 7;
15.        cnt++)
16.       * (lpReportLine->szAddress + cnt) = * (buf + cnt);

Line 1:  two superfluous pairs of parentheses, could be
    ltoa(lBufIndex*16, buf, 16);

Lines 3-5:  far clearer if written as
    for (cnt = 6; cnt > len; cnt--)

Line 10.  buf is actually an array, not a pointer.  Clearer as
    buf[shift] = buf[shift-1];
    which would save four operators.

But all such comments pale into insignificance when you realise that
_in context_ the whole chunk can be written as

 1.     sprintf(lpReportLint->szAddress, "%06lX", lBufIndex);

Here's the second of the two examples:

 1.     itoa ((int)ch, cHex, 16);
 2.     if (cHex[1] == NULL)
 3.     {
 4.       cHex[1] = cHex[0];
 5.       cHex[0] = '0';
 6.       cHex[2] = NULL;
 7.     }
 8.     * (lpToHexStr + (cnt * 3)) = ' ';
 9.     * (lpToHexStr + (cnt * 3) + 1) = cHex[0];
10.     * (lpToHexStr + (cnt * 3) + 2) = cHex[1];

Lines 2, 6:  a type error.  NULL is a POINTER.  The NUL character is '\0'.

Once again, in context the whole thing can be collapsed to a single line:

 1.     sprintf(lpToHexStr + cnt*3, " %02X", ch);

Now there is one thing which partly legitimates this, which is that the
code is Win/DOS code, and you have all that near/far/huge nastiness.  I
leave it to the reader to figure out how an author who provides his own
.DLL with a bunch of "far" string functions could have handled this.

--
"conventional orthography is ... a near optimal system for the
 lexical representation of English words." Chomsky & Halle, S.P.E.
Richard A. O'Keefe; http://www.*-*-*.com/ ~ok; RMIT Comp.Sci.



Sun, 26 Jul 1998 03:00:00 GMT  
 But DO C hackers code concisely?

[ ... ]

Quote:
>But all such comments pale into insignificance when you realise that
>_in context_ the whole chunk can be written as
> 1.     sprintf(lpReportLint->szAddress, "%06lX", lBufIndex);

[ ... ]

Quote:
> 1.     sprintf(lpToHexStr + cnt*3, " %02X", ch);
>Now there is one thing which partly legitimates this, which is that the
>code is Win/DOS code, and you have all that near/far/huge nastiness.  I
>leave it to the reader to figure out how an author who provides his own
>.DLL with a bunch of "far" string functions could have handled this.

I'd guess that the original intent _may_ have been to reduce executable
size since some are convinced that a function like sprintf must be huge
and will bloat executable tremendously.  Fortunately, handing "far"
pointers AND reducing excutable size is simple: just use wsprintf
instead of sprintf.  wsprintf expects "far" pointers, and is part of
Windows itself, so using it doesn't link any code into your executable.

[Any further discussion on this should go to a windows newsgroup. -mod]



Tue, 28 Jul 1998 03:00:00 GMT  
 But DO C hackers code concisely?
[Snip]
Quote:

> But all such comments pale into insignificance when you realise that
> _in context_ the whole chunk can be written as

>  1.     sprintf(lpReportLint->szAddress, "%06lX", lBufIndex);
> I won't defend the coding style, but I will defend the avoidance of

sprintf().  When you build a DLL using MS Visual C/C++, a number of
standard library functions are not permitted - including the printf
and scanf family.  Thus, when developing Windows tools it is unwise
to rely on these functions - you might want to include the tools in
a DLL.

Yes I do think that MS leaving these functions out is realy stupid,
but you have to work with the tools you have.

--
#####################################################################

Emmenjay Consulting   http://www.hutch.com.au/~emmenjay/emmenjay.html
#####################################################################



Sun, 02 Aug 1998 03:00:00 GMT  
 But DO C hackers code concisely?

Quote:
> When you build a DLL using MS Visual C/C++, a number of
> standard library functions are not permitted - including the printf
> and scanf family.  Thus, when developing Windows tools it is unwise
> to rely on these functions - you might want to include the tools in
> a DLL.

> Yes I do think that MS leaving these functions out is realy stupid,
> but you have to work with the tools you have.

What conceivable use could there be for either printf or scanf in a
Windows DLL? The very nature of Windows I/O would cause them to only
produce garbage. I can't think of any reason why they would be in
a Windows library (with the exception of a 'QuickWin' type program, but
that is a different story and printf and scanf are in those libraries).

        Bob.



Mon, 03 Aug 1998 03:00:00 GMT  
 But DO C hackers code concisely?

Quote:


>[Snip]

>> But all such comments pale into insignificance when you realise that
>> _in context_ the whole chunk can be written as

>>  1.     sprintf(lpReportLint->szAddress, "%06lX", lBufIndex);
>> I won't defend the coding style, but I will defend the avoidance of
>sprintf().  When you build a DLL using MS Visual C/C++, a number of
>standard library functions are not permitted - including the printf
>and scanf family.  Thus, when developing Windows tools it is unwise

    i'm not sure i actually believe that MS Visual C/C++ is
    _that_ broken.  sprintf() does not in any way assume the
    existence of a console, and there is _no_ reason why a
    compiler of suitable quality (or standardness) cannot
    implement it. (fortunately, the Windows compiler that I use
    has no problem with DLLs that call sprintf()).

    wsprintf() is essentially sprintf() without floating point
    support.   since it's provided by the "OS" you will
    presumably save a little space in your objects, but that
    seems to be small gain for the loss of functionality and the
    probable (marginal) peformance hit.

 --xmsb



Tue, 04 Aug 1998 03:00:00 GMT  
 But DO C hackers code concisely?

Quote:


> >What conceivable use could there be for either printf or scanf in a
> >Windows DLL?

> The sprintf and sscanf variations do come in handy even when the I/O
> capabilities doesn't match the expectations of stdio.h - so does
> fprintf and fscanf in Windows - there is no 'terminal' concept but
> there *are* disk files.

sprintf and sscanf CAN be used in a DLL. The message that I was commenting
on indicated that Microsoft was "stupid" for not allowing printf and scanf
in DLLs. Again, there would be no use for printf and scanf in a DLL so I don't
consider it particularly stupid to make them unavailable. As you say, there
could be all sorts of uses for sprintf and sscanf, but they are not the same
as printf and scanf.

        Bob.



Wed, 05 Aug 1998 03:00:00 GMT  
 But DO C hackers code concisely?

I guess that I jumped the gun on sscanf in DLLs. I just checked
it out and you are right, it is not available in a DLL.
I wonder why that is?

        Bob.



Wed, 05 Aug 1998 03:00:00 GMT  
 But DO C hackers code concisely?

Quote:
> What conceivable use could there be for either printf or scanf in a
> Windows DLL?

Probably nothing, but sprintf and sscanf can be handy from time to time.

--


Publib 0.5: ftp://ftp.cs.helsinki.fi/pub/Software/Local/Publib/



Wed, 05 Aug 1998 03:00:00 GMT  
 But DO C hackers code concisely?
:

:
: > When you build a DLL using MS Visual C/C++, a number of
: > standard library functions are not permitted - including the printf
: > and scanf family.  Thus, when developing Windows tools it is unwise
: > to rely on these functions - you might want to include the tools in
: > a DLL.
: >
: > Yes I do think that MS leaving these functions out is realy stupid,
: > but you have to work with the tools you have.
:
: What conceivable use could there be for either printf or scanf in a
: Windows DLL? The very nature of Windows I/O would cause them to only
: produce garbage. I can't think of any reason why they would be in
: a Windows library (with the exception of a 'QuickWin' type program, but
: that is a different story and printf and scanf are in those libraries).

Note that Michael Smith said the printf and scanf *families* of
functions; these include sprintf and sscanf.

Microsoft does supply the - almost - similar wsprintf and vwsprintf
functions as part of the Windows API, but these are poor substitutes.

We're straying from system-independent C here; I would suggest sending
followups to comp.os.ms-windows.programmer.misc.



Wed, 05 Aug 1998 03:00:00 GMT  
 But DO C hackers code concisely?
I gave the example of complex code that could have been replaced by
tiny calls to sprintf.

Quote:

>Yes I do think that MS leaving these functions out is realy stupid,
>but you have to work with the tools you have.

This doesn't in the least spoil my argument.  Assume that leaving the
printf() and scanf() _families_ out of the library used with DLLs is a
good decision, and ignoring wsprintf(),
(a) This wasn't a DLL, it was a complete program.
(b) Converting integers from binary to text is pretty useful.  If sprintf()
    is not available, or if efficiency is a concern and sprintf() proves slow,
    the answer is to write functions

        struct Integer_Format {
            unsigned char base; /* 2, 8, 10, 16 */
            unsigned char pad ;
            unsigned char width; /* a minimum value */
        };
        static const struct Integer_Format plain = {10, ' ', 1};

        ltostr(char *buf, long val, struct Integer_Format *);
        ultostr(char *buf, unsigned long val, struct Integer_Format *);

    or something similar, and stick them in your personal library.

--
Election time; but how to get Labour _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.



Sun, 09 Aug 1998 03:00:00 GMT  
 But DO C hackers code concisely?

Quote:
>sprintf and sscanf CAN be used in a DLL. The message that I was commenting
>on indicated that Microsoft was "stupid" for not allowing printf and scanf
>in DLLs.

Actually it talked about the printf and scanf *family* (I just
checked). But let's not get involved over this.

--
Henning Makholm - math and CS student - University of Copenhagen



Sun, 09 Aug 1998 03:00:00 GMT  
 But DO C hackers code concisely?

Quote:
>I guess that I jumped the gun on sscanf in DLLs. I just checked
>it out and you are right, it is not available in a DLL.
>I wonder why that is?
>    Bob.

This is what Microsoft's ``Knowledge Base'' has to say about it:

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

PSS ID Number: Q76684
Article last modified on 08-02-1995

3.00 3.10

WINDOWS

----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft Windows Software Development Kit (SDK) for Windows
   versions 3.0 and 3.1
----------------------------------------------------------------------

SUMMARY
=======

The Microsoft C run-time library function sscanf is not compatible for
use
with a dynamic-link library (DLL) for the Microsoft Windows graphical
environment.

WSSCANF is a file in the Software Library that can serve as a limited
replacement for this function.

Download WSSCANF.EXE, a self-extracting file, from the Microsoft
Software
Library (MSL) on the following services:

 - CompuServe
      GO MSL
      Search for WSSCANF.EXE
      Display results and download

 - Microsoft Download Service (MSDL)
      Dial (206) 936-6735 to connect to MSDL
      Download WSSCANF.EXE

 - Internet (anonymous FTP)
      ftp ftp.microsoft.com
      Change to the \SOFTLIB\MSLFILES directory
      Get WSSCANF.EXE

MORE INFORMATION
================

The sscanf(), fprintf(), and scanf() functions are not available for
Windows DLLs.

There are two factors that cause these functions to be incompatible:

1. These functions rely on near pointers.

2. These functions expect SS == DS.

Because neither of these conditions is true when a function in a DLL
uses data from an application, these functions are not available.

The WSSCANF file in the Software Library contains the source code to a
wsscanf() function that can serve as a limited replacement for the
sscanf
function. It does not support floating point. The wsscanf() code is
based
on the sscanf() source code in the Microsoft C 6.0a run-time library.
The
source code has been modified to work correctly in a DLL, and requires
that
all parameters are specified as FAR pointers. The following code
demonstrates using the wsscanf() function:

   char   szBuf[] = "1 3 b000:0200";
   int    nValue1, nValue2;
   LPSTR  lpPtr;

   wsscanf(szBuf, "%d %d %p", (int FAR *)&nValue1,
            (int FAR *)&nValue2, (LPSTR FAR *)&lpPtr);

NOTE: The first two parameters are not explicitly typecast in the
function
call. The function prototype typecasts the first two parameters
automatically; however, the application must typecast each subsequent
parameter. If the application does not typecast each parameter, when
the
application calls wsscanf an unrecoverable application error (UAE)
occurs.

The wsscanf() function does not support floating point numbers (the
%f,
%g, and %e format specifiers).

Additional reference words: 3.00 3.10 softlib WSSCANF.EXE
KBCategory: kbprg kbfile
KBSubcategory: TlsMisc
=============================================================================
Copyright Microsoft Corporation 1995.

==
Miguel Carrasquer Vidal                     ~ ~
Amsterdam                   _____________  ~ ~

========================== Ce .sig n'est pas une .cig



Sun, 09 Aug 1998 03:00:00 GMT  
 But DO C hackers code concisely?

Quote:
>We've heard a bit in this newsgroup recently about the wonders of C notation
>and how concise it can be.  I find myself wondering whether real C code is in
>fact concise.  There is no dispute that it CAN be.  What I wonder is whether
>it IS.

>Here's a real example taken from a book that I have found very helpful.
>The book is about Windows support tools, not primarily about C coding.
>Here's the first of two examples.

These samples _are_ pretty wordy, no doubt.  As to the fact that both
can be adequately replaced with sprintf() calls can probably be
explained as: 1. ignorance; or 2. efficiency by writing a special-
purpose function instead of going through a general-purpose function.
How valid the latter argument is depends on the application, of
course.

Like many other things, though, C _allows_ compact expressions, but
does not enforce them, and _this_, IMO, is the more important factor
in C's popularity.  How you choose to use your freedom is your
business, except where it impacts others.  In that case, the main
thing is that the code have the indefinable property "style".  (Aside:
Gallagher understands style.)  IMO, the code snippets you presented
don't have style.

Quote:
>Line 1:  two superfluous pairs of parentheses, could be
>    ltoa(lBufIndex*16, buf, 16);

I must make a specific comment here, though: While the original was
unquestionably paren-happy, don't discount code where extra parens
really _do_ add to clarity.  If the measure of "code goodness" is the
byte count of the source file, then I quit because I'm a rotten coder.
I regularly place subexpressions in parens except where the order of
operations is _very_ straightforward; this is my defense against C's
lengthy order-of-operations table.

However, I do appreciate C's compactness of expression on occasion.
Sometimes a more compact expression with a really good comment can be
better than a one-statement-per-line block without any comments.
String parsing routines are very often this way.  (Isn't it ironic
that the code snippets you showed _were_ string parsing routines?)

= Warren --



Sun, 09 Aug 1998 03:00:00 GMT  
 But DO C hackers code concisely?

Quote:
>What conceivable use could there be for either printf or scanf in a
>Windows DLL? The very nature of Windows I/O would cause them to only
>produce garbage.

Well, the C standard *requires* them.  If you haven't got printf() and
scanf(), you haven't got a "hosted" C implementation.
        printf(~~1~~)           ===     fprintf(stdout, ~~1~~)
and     scanf(~~2~~)            ===     fscanf(stdin, ~~2~~)
so the problem is not printf and scanf per se but stdin and stdout, and
if you haven't got _them_ you haven't got a conforming "hosted" C
implementation either.

One very good reason for having them in the library is precisely to catch
code which has been ported to Windows but incompletely.  Since Microsoft C
has exceptions, I would think it appropriate for
        - input from stdin, however expressed
        - output to stdout, however expressed
to raise an exception, and for the library to define printf &c so that user
code cannot accidentally rely on defining them to do something different.
getchar, putchar, printf, scanf, could all share the same few "raise
exception" bytes.

In any case, this is irrelevant to the original example, which used
        sprintf
not printf.

--
Election time; but how to get Labour _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.



Sun, 09 Aug 1998 03:00:00 GMT  
 But DO C hackers code concisely?


Quote:
>What conceivable use could there be for either printf or scanf in a
>Windows DLL? The very nature of Windows I/O would cause them to only
>produce garbage. I can't think of any reason why they would be in
>a Windows library (with the exception of a 'QuickWin' type program, but
>that is a different story and printf and scanf are in those libraries).

He did say the printf and scanf *family*. I use sprintf and sscanf all
the time, with fprintf coming a close second. vsprintf is handy for
writing functions that build up strings.

Yes, I think it's insane of MS as well. Can't somebody write a DLL with
them in, or am I misunderstanding the way Windows DLL's work?

--
-------------------------------------------------------------------------------
   Why do people surf the Information Superhighway? Won't they get run over?
               http://www-hons-cs.cs.st-andrews.ac.uk/~dg
              Sun-Earther David Daton Given  of Lochcarron



Sun, 09 Aug 1998 03:00:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Newbie: separate big .cs file into small .cs files

2. Include code in other Cs files

3. newbe/cs student, need help w/ code

4. Compile CS source code using ICodeCompiler

5. cs source code

6. What am i doing wrong in this code?

7. Code: What am I doing wrong?

8. Beware of "C" Hackers

9. A ask for all Hacker

10. for programmers and hackers

11. Hackers!

12. ATTN: C hacker who loves Awk

 

 
Powered by phpBB® Forum Software