Hi-tech C libc _doprnt.c fprintf.c needed

What arch? HI-TECH does not use libc.

Include library sources, yes; libc, no.

Provide references to the forum posts please so I read exactly what you have read.

arch=i8096. This product does have a C library which is named (prefix)libc.lib where (prefix) is '96' or '196' for various flavors. Indeed the header files include conditional compilation for Unix, Dos, non-hosted, etc. and it is a full-fledged canonical libc implementation.

Today I found a pdf of the Hi-Tech C ref manual for the PICC18 V9 Compiler which has manpages for the C library functions (a libc).

Since no one replied with any indication of having the source, I have been writing _doprnt and the printf-family functions; I found the XINU 7.9 source base helpful for an approach. My code works except for issues with parsing args off the call stack correctly for certain format types in printf (using stdarg macros).

I remain very interested to see the Hi-Tech source for these functions.

You asked for a citation of a Hi-Tech forum post regarding these sources:

Mark Pappin (Hi-Tech Staff) outlines a source patch procedure for 'printf'; partially quoting:

"The printf() routines in the pre-compiled libraries shipped with our H8/300 compiler have a bug in their handling of hex formats. If this affects you, you can fix your library as follows:

Note: Make a backup copy of each .C and .LIB file before you modify it, just in case Bad Things happen.

• Copy SOURCES\DOPRNT.C into a new directory and..."

Regards,

Michael

Then you don't need HI-TECH. libc is here:

I have the _doprnt source for four of their toolchains all of which have HI-TECH copyright notices, not GNU GPL or LGPL license language, and look radically different than libc.

HI-TECH's free PICC-Lite does not come with library source. You could try downloading their Pacific C to see if it comes with library source.

Nothing in that thread or on the distribution media for my four toolchains suggests that I can give away the source.

I suggest getting the files from the above-linked libc or by e-mailing snipped-for-privacy@htsoft.com for the files.

A reference to uClibc may have been more appropriate than this one... In any case there are more compact implementations for reference. I never equated the term 'libc' with 'glibc' or GNU libc... Even SVR4 libc is available in OpenSolaris and the BSD variants provide another good alternative. I've found that the XINU code is a good small-footprint point-of-reference.

(snip)

I had no preconceived notions about copyright on those; all of my Hi-Tech header files are completely devoid of copyright notices. This toolchain is freely distributed on a number of sites and many library object module variants are to be found; obviously the sources exist for this to occur. It is an obsolete product with no support and one my find references to others seeking the same sources in 'Net archives; ergo my original request and reference to other obsolete Hi-Tech products.

I will post my code when it is debugged.

Regards,

Michael

Done and working.

BTW, Does anyone know how to stop compiler warning messages about pointers to functions passed as args?:

_doprnt(fmt, fputc, ((void *)0), args); ^ illegal conversion between pointer types (warning)

(the carat is pointing to 'fputc' in case text formatting is lost)

The functions are declared thusly:

extern void _doprnt(char *fmt, int (*func)(), void *farg, va_list args); extern int fputc(int, FILE *);

Note that this warning always happens when passing a pointer-to- function in any function call; I've tried casting, different storage classes and types, etc. with no difference. The code works in any case.

This may be an artifact of this _old_ compiler but I'm interested to hear if this happens on other Hi-Tech C compilers.

Regards,

Michael

I think you need to specify the full signiture of the function, like e.g.

extern void _doprnt(char *fmt, int (*func)(int, FILE*), void *farg, va_list args);

args);

Thanks, that did the trick; in the situation where the caller passes a number of different functions as args, each having different signatures (as in a function table), evidently one must live with the warnings(?).

Regards,

Michael

args);

I think so; ask in comp.lang.c.

Also see

Basically you have to cast to a "generic" function pointer when you call your _doprnt(). then when you call your passed function you need to convert back again.

Perhaps (untested):

void _doprnt(char *fmt, void (*func)(), void *farg, va_list args) { ... /* cast func and call it with args */ ((int (*func)(int, FILE*)) func)(farg_int, farg_file); }

...

/* casts fputc to generic function pointer */ _doprint(fmt, (void (*func())) fputc. ((void*)0), args);

...

Horrid I'm afraid... You would probably use some typedefs to simplify this.

And without a valid serial number, no such files will be forthcoming.

mlp (work hat off, catching up on Usenet - Hi, Dan)

Hi Mark!

The OP states:

Did lib source come with those older architectures? Just curious.