C find out list of C functions supported in FreeBSD

DOS/NT Kingdom
I. Philippe Kahn made Bill Gate crazy. Turbo C (~ 40 USD) vs. MS (~ 400 USD).
II. In Windows we didn't have src/, only Win32 API. That's all.
III. We had to wait till someone like Peter Norton or Mark Russinovich show us more!
IV. There was also system-specific stuff, e.g. dos.h, conio.h, windows.h, etc.
V. And C++ classes wrapper around Win32 APIs made things worse.
VI. But, UNIX has src/

UNIX/BSD Empire
I. Pick a random c(7) file in the src/
II. Follow up its headers at sys/sys/ and include/
III. Many functions, constant and blocks of code in the translation unit have comments. Some are obvious from its context.
IV. Back and forth between .c (s) and .h (s)
V. Learn more at man(3) <-->>man(2) <-->>man(9)
VI. It's not just ANSI C, there's POSIX headers too. The best next step to learn about ANSI C, POSIX, XSI, SUS and their interfaces, headers, etc:
Stevens' Advanced Programming in the Unix Environment book.

i shall take the UNIX/BSD Empire. very much useful. esp, from man2 to man9.
 
  • Thanks
Reactions: a6h
Seriously??? Can someone explain why, please?
Java was designed to address several problems that C/C++ suffered from, including memory leaks, and ABI compatibility. I'm not wild about Java myself, but come on, let's have an informed conversation, rather than a digital shouting match... :rolleyes:
 
Seriously??? Can someone explain why, please?
Java was designed to address several problems that C/C++ suffered from, including memory leaks, and ABI compatibility. I'm not wild about Java myself, but come on, let's have an informed conversation, rather than a digital shouting match... :rolleyes:
Java has it's own security issues. I agree some of the basic security issues like buffer overflows, heap overflows, integer overflows, format string security issues might be addressed by Java. but it has also brought in other security issues.

JRE has many security issues to say the least.
 
Seriously??? Can someone explain why, please?
Java was designed to address several problems that C/C++ suffered from, including memory leaks, and ABI compatibility. I'm not wild about Java myself, but come on, let's have an informed conversation, rather than a digital shouting match... :rolleyes:
I beg your pudding.

Java was intended to be the last language (I think), and all applications could run on all and any device.

Well java is now running on millions - billions of devices. And applications - in java - are still as device dependent as ever.

When I get a program from the ports, it is not written in java.

Great idea, but I am afraid it has not worked.

Additionally (I believe) java is no longer intended to be free.

Dear astyle, I may be an old fart. I am going to stick with C.
 
The Java JVM is also written in C and C++ so inherits all of their security limitations. It is also ginormous, almost on par with operating systems. All of that code cannot be verified and I really do not want all that stuff running on something that needs to be security critical.

You can't just bolt this on-top of an "unsafe" platform. It needs to be written from the ground up. I believe Rust comes closest but the weak points are still the native bindings to underlying systems.

(Portability is a different matter. However I can not say that Java is portable. The JVM again is millions of lines of very platform specific C and C++ code and in terms of the JIT, low level architecture specific assembler. Very few people can port this kind of complexity to a new platform. Whereas a C compiler can be written realistically in a month. Some guys better than me can do it in a weekend ;)
 
Java has it's own security issues. I agree some of the basic security issues like buffer overflows, heap overflows, integer overflows, format string security issues might be addressed by Java. but it has also brought in other security issues.

JRE has many security issues to say the least.
I'd say there's kind of a difference between execution safety (making sure programs don't crash and take the machine down in the process) and security topics like unauthorized access. My point was about execution safety.

FWIW, I actually disable the Java options when I compile my ports.
 
That isn't really Java. It is the VM concept that makes "execution safety" work.

For example, compile C/C++ to WebAssembly and run it in the Node VM and you get similar safety guarantees to Java.

But this isn't MS-DOS. Crashing programs do not take the machine down any more. Memory also cannot be leaked by terminated applications.
 
That isn't really Java. It is the VM concept that makes execution safety work.

For example, compile C/C++ to WebAssembly and run it in the Node VM and you get similar safety guarantees to Java.

But this isn't MS-DOS. Crashing programs do not take the machine down any more. Memory also cannot be leaked by terminated applications.
In the glory days of Borland Turbo C, execution safety was a priority, and a VM concept was one way to make it work. The alternative was was to make use of semaphores to avoid race conditions in critical sections of code. The idea of atomic operations was just beginning to gain steam at that time, and found a home in relational databases as a popular use case. But even a competent C programmer can occasionally get lost trying to wrap sections of code into a block that is managed by a semaphore.

Unauthorized access (account privileges) was not as much of an issue back then as it is today, and Java was not the bloated abomination it is today.
 
In the glory days of Borland Turbo C, execution safety was a priority, and a VM concept was one way to make it work.
There was actually a really cool breakdown from John Carmack on this kind of technology for writing game mods for his Quake engine in a safe way. He looked at Java, Lua and C. Annoyingly I can't find his old .plan file where he documented it. In the end he wrote Q3VM and modified the LCC C compiler to emit bytecode for this VM.
Here is a standalone fork (separated from the engine): https://github.com/jnz/q3vm

It is an ongoing problem and it seems no-one is 100% happy with the solutions.
The alternative was was to make use of semaphores to avoid race conditions in critical sections of code. The idea of atomic operations was just beginning to gain steam at that time, and found a home in relational databases as a popular use case. But even a competent C programmer can occasionally get lost trying to wrap sections of code into a block that is managed by a semaphore.
This is to do with multi-threading (Something that came much after Borland Turbo C and MS-DOS!). However all bets are off with this. Java and C are equally unsafe unless a skilled developer correctly uses mutexes and semaphores. For example pushing back into a list in Java or C++ at the same time results in race conditions and munges the internal state (data size not matching recorded count, etc).

A high number of JVM crashing bugs have been due to the internal multi-threading problems. It must be so crazy complex for a monolith that big!

I think the atomic operations in databases (The 'A' in 'ACID') is only loosely related to atomic in programming. They work in very different ways. COMMIT/ROLLBACK is something that no programming language really provides (perhaps something like Lua if you serialize and store the execution state?)
 
There is no such concept as execution safety. What you are talking about are memory safety and sandboxing (two completely independent things, by the way).

I think the atomic operations in databases (The 'A' in 'ACID') is only loosely related to atomic in programming. They work in very different ways. COMMIT/ROLLBACK is something that no programming language really provides (perhaps something like Lua if you serialize and store the execution state?)
Transactional memory was making some noise right before Intel's TSX fiasco.
 
JRE has many security issues to say the least.
What? The only security issue with Java is that their original policy-based sandboxing model doesn't work. But that is completely irrelevant for the typical Java usage (various enterprise server apps/backends).
 
There is no such concept as execution safety. What you are talking about are memory safety and sandboxing (two completely independent things, by the way).


Transactional memory was making some noise right before Intel's TSX fiasco.
Memory safety is implemented by paying attention to hardware addresses in the C code. Sandboxing is ultimately an implementation of memory safety. But, Intel's TSX fiasco??? links, please.
 
the main purpose of Java being invented is not from security perspective, but for platform independent code. C was very popular in creating pretty much everything in low level. The problem of flat memory is not only C problem, but the design of the OS and the feature of the hardware available at that time. remember, no protected memory and only real mode.

in fact, Dennis Ritchie once said, the security of these memory safety issues, falls under the responsibility of the developer. however, the enormous amount networking software, server applications and other were written in C, brought in all kind of security vulnerabilities (like stack overflow). Java was only a better replacement, but not the exact purpose of solving this issue.

I don't know if someone would use Java to create kernels, or networking software.

In fact, the rust programming language is trying to solve all these issues, and at the same time trying to be closer with the hardware. so speed is also guaranteed.
 
Seriously??? Can someone explain why, please?
Java was designed to address several problems that C/C++ suffered from, including memory leaks, and ABI compatibility. I'm not wild about Java myself, but come on, let's have an informed conversation, rather than a digital shouting match... :rolleyes:
Because Java, so JRE/JDK, are just ugly clusterfucks! First of all it's slogan "write once, run everywhere" turned out in reality to "write once, debug everywhere."

You might still remember Macromedia, later Adobe Flash? That proprietary piece of software, that infected many web sites and on which Youtube ran before HTML5 was being born, which Steve Jobs killed single handedly, and is now finally dead?

Flash was being considered to be one of the worst pieces of software ever in terms of security. Well this was until some security researchers took a look at Java. It turned out that JRE's played in a league of their own, dwarfing Flash in comparison.

The most popular choice at the moment for doing memory safe low level programming is Rust, because it has some protection builtin which C has not.
 
JRE has many security issues to say the least.
For example?
Java was intended to be the last language (I think), and all applications could run on all and any device.
Java was originally designed to run on embedded devices, which is hilarious in retrospect. It never caught on there or on the desktop, but it has a large footprint in back-end systems.
When I get a program from the ports, it is not written in java.
Not sure what you mean. The ports framework supports Java software. I personally use Eclipse and Jetty on Freebsd.
Great idea, but I am afraid it has not worked.
While it's certainly not perfect, it has had more longevity and has retained more relevance than things like CORBA or Ruby on Rails. I expect it to outlast Node as well.
Additionally (I believe) java is no longer intended to be free.
This is one thing Sun did right. They open-sourced Java before they got acquired by Oracle. Java is free and freely available on many platforms nowadays thanks to Openjdk.
Dear astyle, I may be an old fart. I am going to stick with C.
By all means do, but don't pretend it doesn't have any flaws. The problems with C have driven the search for new languages and platforms for at least two decades now. You could argue that its greatest flaws are also its biggest strengths, but the fact is it's not for everyone.
 
By all means do, but don't pretend it doesn't have any flaws. The problems with C have driven the search for new languages and platforms for at least two decades now. You could argue that its greatest flaws are also its biggest strengths, but the fact is it's not for everyone.

Yup.
 
Flash was being considered to be one of the worst pieces of software ever in terms of security. Well this was until some security researchers took a look at Java. It turned out that JRE's played in a league of their own, dwarfing Flash in comparison.
This is an extraordinary claim. Got anything to back it up?
 
This is an extraordinary claim. Got anything to back it up?
Depends on how you look at it. Java tried to be "the hot thing everywhere", including the web. Flash muscled in on the web territory, and Java got pushed off the web into the backroom to grow fat and unwieldy, feeding mostly on the databases. Flash was too flashy for its own good, sand in the eyes was prioritized over sensible security, and so, Flash flamed out. By now, web and backroom databases are two different sports altogether, let alone leagues.
 
the main purpose of Java being invented is not from security perspective, but for platform independent code. C was very popular in creating pretty much everything in low level. The problem of flat memory is not only C problem, but the design of the OS and the feature of the hardware available at that time. remember, no protected memory and only real mode.

in fact, Dennis Ritchie once said, the security of these memory safety issues, falls under the responsibility of the developer. however, the enormous amount networking software, server applications and other were written in C, brought in all kind of security vulnerabilities (like stack overflow). Java was only a better replacement, but not the exact purpose of solving this issue.

I don't know if someone would use Java to create kernels, or networking software.

In fact, the rust programming language is trying to solve all these issues, and at the same time trying to be closer with the hardware. so speed is also guaranteed.
Yes, people do use Java to create kernels. Many universities actually use Java to teach OS concepts like IPC and process scheduling. My class certainly did that. There's quite a few books that come with Java source code that you can follow along when learning about stacks. And yes, that same stuff includes basic networking. Sometimes, implementation of some missing functionality (using Java, of course) is left as an exercise at end of the chapter.
 
C is a low level language. You use it when you don't want to program in assembler.
.h files can be very unreadable. Certainly when api-writers overuse macro's.
 
Back
Top