7 ms·

This is really cool. I admire your bravery. I noticed that certain options are hardcoded (such as the port number). As someone with very little experience in a

by k1ns 8y ago

This is really cool. I admire your bravery. I noticed that certain options are hardcoded (such as the port number). As someone with very little experience in assembly, how difficult would it be to make this dynamic via environment variables?

haolez 8y ago
That's probably not a good model to fit in assembly code. It's easier to have a wrapper in another language as the launcher and have it set the variables in the assembly code and build the binary.
- getcrunk 8y ago
  Why?
  - SSLy 8y ago
    for starters, you'd need a text parser
    - admax88q 8y ago
      Something you already have if you're building an http server in asm...
  - haolez 8y ago
    I’m assuming that there is a need to dynamically configure things like the port in the parent’s environment. However, for an assembly tool, it might make sense to simply have it hard coded and save the extra complexity. My launcher script suggestion is a possible solution to this, but I would just hard code the port and ship it without a launcher myself. The suckless projects make use of hard coded configurations in their C programs. The principle is the same.
  - kjeetgill 8y ago
    speculation: Maybe it's simpler to just bake a string into the binary and hardcode the pointer to at every use than futz around with strings in asm? But if you're already doing the rest of it in asm why would that scare you?
- captoblivious 8y ago
  A wrapper that recompiles every time you run or change an option? lol. HN has caught the reddit cancer. environment variables are after argv. http://asm.sourceforge.net/articles/startup.html#st http://asm.sourceforge.net/articles/startup.html#st
  - saagarjha 8y ago
    While the point you are making is correct, you could have presented it in a less abrasive way. Not everyone is aware of how environment variables are passed to programs, or pieced together that char envp is also available in assembly.
    - alxlaz 8y ago
      If we're talking about bad ways to present knowledge, the parent comment could also have been "I really don't know much on this topic so I'd rather not speculate" ;-).
jxub 8y ago
Well, it's not mine but I'm sure it certainly was quite a challenge to build, props to the author for accomplishing that.
alxlaz 8y ago
It wouldn't be that difficult, it would only require some libc-related magic (but I haven't read much of the asmttpd source code to know how much of it is in there). IIRC, environment variables are passed from the parent process to the child in the form of a "naive" array of strings, so the truly unpleasant parts of this, like parsing text from a config file, are already taken care of.
tormeh 8y ago
Slightly off topic, but I don't get environment variables. To me they look like implicit options that are based on what shell session you're currently in. Stuff that hangs around waiting to kill you when you're not looking, like a cecum. Why would anyone want environment variables when you can have config files or explicit options instead?
- tlarkworthy 8y ago
  I am very pro environment vars and consider files an anti pattern. Files are like globals, sibling processes end up sharing state, plus they survive longer than their use case. Env variables cascade, which is why they have wider uses than program args. You can organize a system as a group of processes and envs are a good way to share state and abstract out the details like prod vs staging without affecting the program implementation.
  - kjeetgill 8y ago
    I'd say it's really about size. A few dozen configs in environmental vars, sure. But once you expand beyond that, need to manage variants of them, need to compose them from fragments you start to see benefits from something more structured like xml, toml, json, or yaml etc.
    - tlarkworthy 8y ago
      I just start loading env variables from files, e.g. source blah.env This way, my bash environment mirrors the task I am working on
    - ConcernedCoder 8y ago
      I'd say it's really about size. My wife assures me that size doesn't matter, it's actually the way you use your configs to manage your environmental vars. (sorry, I just couldn't help myself...)
  - gpderetta 8y ago
    Envs are also globals. Dynamically scoped globals. They are evil and allow all kind of spooky action at distance, but sometimes they are a necessary evil.

by k1ns 8y ago

haolez 8y ago

That's probably not a good model to fit in assembly code. It's easier to have a wrapper in another language as the launcher and have it set the variables in the assembly code and build the binary.

getcrunk 8y ago
Why?
- SSLy 8y ago
  for starters, you'd need a text parser
  - admax88q 8y ago
    Something you already have if you're building an http server in asm...
- haolez 8y ago
  I’m assuming that there is a need to dynamically configure things like the port in the parent’s environment. However, for an assembly tool, it might make sense to simply have it hard coded and save the extra complexity. My launcher script suggestion is a possible solution to this, but I would just hard code the port and ship it without a launcher myself. The suckless projects make use of hard coded configurations in their C programs. The principle is the same.
- kjeetgill 8y ago
  speculation: Maybe it's simpler to just bake a string into the binary and hardcode the pointer to at every use than futz around with strings in asm? But if you're already doing the rest of it in asm why would that scare you?
captoblivious 8y ago
A wrapper that recompiles every time you run or change an option? lol. HN has caught the reddit cancer. environment variables are after argv. http://asm.sourceforge.net/articles/startup.html#st http://asm.sourceforge.net/articles/startup.html#st
- saagarjha 8y ago
  While the point you are making is correct, you could have presented it in a less abrasive way. Not everyone is aware of how environment variables are passed to programs, or pieced together that char envp is also available in assembly.
  - alxlaz 8y ago
    If we're talking about bad ways to present knowledge, the parent comment could also have been "I really don't know much on this topic so I'd rather not speculate" ;-).

jxub 8y ago

Well, it's not mine but I'm sure it certainly was quite a challenge to build, props to the author for accomplishing that.

alxlaz 8y ago

It wouldn't be that difficult, it would only require some libc-related magic (but I haven't read much of the asmttpd source code to know how much of it is in there). IIRC, environment variables are passed from the parent process to the child in the form of a "naive" array of strings, so the truly unpleasant parts of this, like parsing text from a config file, are already taken care of.

tormeh 8y ago

Slightly off topic, but I don't get environment variables. To me they look like implicit options that are based on what shell session you're currently in. Stuff that hangs around waiting to kill you when you're not looking, like a cecum. Why would anyone want environment variables when you can have config files or explicit options instead?

tlarkworthy 8y ago
I am very pro environment vars and consider files an anti pattern. Files are like globals, sibling processes end up sharing state, plus they survive longer than their use case. Env variables cascade, which is why they have wider uses than program args. You can organize a system as a group of processes and envs are a good way to share state and abstract out the details like prod vs staging without affecting the program implementation.
- kjeetgill 8y ago
  I'd say it's really about size. A few dozen configs in environmental vars, sure. But once you expand beyond that, need to manage variants of them, need to compose them from fragments you start to see benefits from something more structured like xml, toml, json, or yaml etc.
  - tlarkworthy 8y ago
    I just start loading env variables from files, e.g. source blah.env This way, my bash environment mirrors the task I am working on
  - ConcernedCoder 8y ago
    I'd say it's really about size. My wife assures me that size doesn't matter, it's actually the way you use your configs to manage your environmental vars. (sorry, I just couldn't help myself...)
- gpderetta 8y ago
  Envs are also globals. Dynamically scoped globals. They are evil and allow all kind of spooky action at distance, but sometimes they are a necessary evil.