[fpc-devel] NowUTC in the RTL

Marco van de Voort marcov at stack.nl
Fri Dec 9 16:55:39 CET 2011


In our previous episode, Michael Van Canneyt said:
> >> Well, you'll have to convince Marco.
> >> But I think it's that time of the month, when he's hard to convince, just for the fun of discussion :)
> >
> > Strange. I had the same feeling. Something random functionality HAD to be
> > put in, damn the consequences or counter arguments.
> 
> Not quite.
> 
> If we're talking about clock_gettime, that was on my agenda since Zeljko pointed out
> their existence, as I stated in my initial post: "it is on my todo list".

Then also add the getres. Without it is useless, or will lead to bad code
that makes assumptions about granularity.
 
> It is a linux kernel call, and therefor earns its place at least in the linux unit, 
> it is the purpose of that unit.

The linux unit is much more lowprio. The problem is more the reason.
 
> Concerning Felipe's functions NowUTC and gettickcount or whatever in sysutils: 
> I am generally neutral, slightly in favour, but mostly just participating 
> in the discussion;
 
> Much like you, I suspect, with the possible difference that you are slightly (or much) 
> against :-)

I'll summarize it:

- I don't like getting requests for addition of new functions to central
  highly portable units that are so whoefully underresearched.  
   - This comes from an urgent need for a windows call. 
   - Implementation of non unix was pretty much nonexistant.
   - it had the danger of dragging in stuff like timezone parsing and
	other possibly distribution and OS specific config files.
- Then there is a suggestion to wave it away with clock_gettime
   - which doesn't exist one some systems.
   - with the intended parameter (MONOTONIC_RAW) that is not portable (did sb check non
	x86(_64) linux?), and essentially a kernel internal's loophole.

And most important of all, I still don't see why this should be in the core
RTL. Syscall, libc or whatever. It is just an liability.

And as far as libc goes, I'm talking about library libc here, not unit libc.
Nobody wants unit libc back, least of all me, since I siderailled it.

But that doesn't meant that libc should be ruled out for all purposes, and
then specially the ones with systemwide userland state like timezones etc.



More information about the fpc-devel mailing list