# Writing a Lint Check: Basics
## Preliminaries
(If you already know a lot of the basics but you're here because you've
run into a problem and you're consulting the docs, take a look at the
frequently asked questions chapter.)
### “Lint?”
The `lint` tool shipped with the C compiler and provided additional
static analysis of C code beyond what the compiler checked.
Android Lint was named in honor of this tool, and with the Android
prefix to make it really clear that this is a static analysis tool
intended for analysis of Android code, provided by the Android Open
Source Project -- and to disambiguate it from the many other tools with
"lint“ in their names.
However, since then, Android Lint has broadened its support and is no
longer intended only for Android code. In fact, within Google, it is
used to analyze all Java and Kotlin code. One of the reasons for this
is that it can easily analyze both Java and Kotlin code without having
to implement the checks twice. Additional features are described in the
[features](../features.html.md) chapter.
We're planning to rename lint to reflect this new role, so we are
looking for good name suggestions.
### API Stability
Lint's APIs are not stable, and a large part of Lint's API surface is
not under our control (such as UAST and PSI). Therefore, custom lint
checks may need to be updated periodically to keep working.
However, ”some APIs are more stable than others“. In particular, the
detector API (described below) is much less likely to change than the
client API (which is not intended for lint check authors but for tools
integrating lint to run within, such as IDEs and build systems).
However, this doesn't mean the detector API won't change. A large part
of the API surface is external to lint; it's the AST libraries (PSI and
UAST) for Java and Kotlin from JetBrains; it's the bytecode library
(asm.ow2.io), it's the XML DOM library (org.w3c.dom), and so on. Lint
intentionally stays up to date with these, so any API or behavior
changes in these can affect your lint checks.
Lint's own APIs may also change. The current API has grown organically
over the last 10 years (the first version of lint was released in 2011)
and there are a number of things we'd clean up and do differently if
starting over. Not to mention rename and clean up inconsistencies.
However, lint has been pretty widely adopted, so at this point creating
a nicer API would probably cause more harm than good, so we're limiting
recent changes to just the necessary ones. An example of this is the
new [partial analysis](partial-analysis.md.html) architecture in 7.0
which is there to allow much better CI and incremental analysis
performance.
### Kotlin
We recommend that you implement your checks in Kotlin. Part of
the reason for that is that the lint API uses a number of Kotlin
features:
* **Named and default parameters**: Rather than using builders, some
construction methods, like `Issue.create()` have a lot of parameters
with default parameters. The API is cleaner to use if you just
specify what you need and rely on defaults for everything else.
* **Compatibility**: We may add additional parameters over time. It
isn't practical to add @JvmOverloads on everything.
* **Package-level functions**: Lint's API includes a number of package
level utility functions (in previous versions of the API these are all
thrown together in a `LintUtils` class).
* **Deprecations**: Kotlin has support for simple API migrations. For
example, in the below example, the new `@Deprecated` annotation on
lines 1 through 7 will be added in an upcoming release, to ease
migration to a new API. IntelliJ can automatically quickfix these
deprecation replacements.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~kotlin linenumbers
@Deprecated(
"Use the new report(Incident) method instead, which is more future proof",
ReplaceWith(
"report(Incident(issue, message, location, null, quickfixData))",
"com.android.tools.lint.detector.api.Incident"
)
)
@JvmOverloads
open fun report(
issue: Issue,
location: Location,
message: String,
quickfixData: LintFix? = null
) {
// ...
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As of 7.0, there is more Kotlin code in lint than remaining Java
code:
Language | files | blank | comment | code
-------------|------:|--------:|--------:|------:
Kotlin | 420 | 14243 | 23239 | 130250
Java | 289 | 8683 | 15205 | 101549
[`$ cloc lint/`]
And that's for all of lint, including many old lint detectors which
haven't been touched in years. In the Lint API library,
`lint/libs/lint-api`, the code is 78% Kotlin and 22% Java.
## Concepts
Lint will search your source code for problems. There are many types of
problems, and each one is called an `Issue`, which has associated
metadata like a unique id, a category, an explanation, and so on.
Each instance that it finds is called an ”incident“.
The actual responsibility of searching for and reporting incidents is
handled by detectors -- subclasses of `Detector`. Your lint check will
extend `Detector`, and when it has found a problem, it will ”report“
the incident to lint.
A `Detector` can analyze more than one `Issue`. For example, the
built-in `StringFormatDetector` analyzes formatting strings passed to
`String.format()` calls, and in the process of doing that discovers
multiple unrelated issues -- invalid formatting strings, formatting
strings which should probably use the plurals API instead, mismatched
types, and so on. The detector could simply have a single issue called
"StringFormatProblems” and report everything as a StringFormatProblem,
but that's not a good idea. Each of these individual types of String
format problems should have their own explanation, their own category,
their own severity, and most importantly should be individually
configurable by the user such that they can disable or promote one of
these issues separately from the others.
A `Detector` can indicate which sets of files it cares about. These are
called “scopes”, and the way this works is that when you register your
`Issue`, you tell that issue which `Detector` class is responsible for
analyzing it, as well as which scopes the detector cares about.
If for example a lint check wants to analyze Kotlin files, it can
include the `Scope.JAVA_FILE` scope, and now that detector will be
included when lint processes Java or Kotin files.
!!! Tip
The name `Scope.JAVA_FILE` may make it sound like there should also
be a `Scope.KOTLIN_FILE`. However, `JAVA_FILE` here really refers to
both Java and Kotlin files since the analysis and APIs are identical
for both (using “UAST”, a universal abstract syntax tree). However,
at this point we don't want to rename it since it would break a lot
of existing checks. We might introduce an alias and deprecate this
one in the future.
When detectors implement various callbacks, they can analyze the
code, and if they find a problematic pattern, they can “report”
the incident. This means computing an error message, as well as
a “location”. A “location” for an incident is really an error
range -- a file, and a starting offset and an ending offset. Locations
can also be linked together, so for example for a “duplicate
declaration” error, you can and should include both locations.
Many detector methods will pass in a `Context`, or a more specific
subclass of `Context` such as `JavaContext` or `XmlContext`. This
allows lint to provide access to the detectors information they may
need, without passing in a lot of parameters (and allowing lint to add
additional data over time without breaking signatures).
The `Context` classes also provide many convenience APIs. For example,
for `XmlContext` there are methods for creating locations for XML tags,
XML attributes, just the name part of an XML attribute and just the
value part of an XML attribute. For a `JavaContext` there are also
methods for creating locations, such as for a method call, including
whether to include the receiver and/or the argument list.
When you report an `Incident` you can also provide a `LintFix`; this is
a quickfix which the IDE can use to offer actions to take on the
warning. In some cases, you can offer a complete and correct fix (such
as removing an unused element). In other cases the fix may be less
clear; for example, the `AccessibilityDetector` asks you to set a
description for images; the quickfix will set the content attribute,
but will leave the text value as TODO and will select the string such
that the user can just type to replace it.
!!! Tip
When reporting incidents, make sure that the error messages are not
generic; try to be explicit and include specifics for the current
scenario. For example, instead of just “Duplicate declaration”, use
“`$name` has already been declared”. This isn't just for cosmetics;
it also makes lint's [baseline
mechanism](../usage/baselines.md.html) work better since it
currently matches by id + file + message, not by line numbers which
typically drift over time.
## Client API versus Detector API
Lint's API has two halves:
- The **Client API**: “Integrate (and run) lint from within a tool”.
For example, both the IDE and the build system uses this API to embed
and invoke lint to analyze the code in the project or editor.
- The **Detector API**: “Implement a new lint check”. This is the API
which lets checkers analyze code and report problems that they find.
The class in the Client API which represents lint running in a tool is
called `LintClient`. This class is responsible for, among other things:
* Reporting incidents found by detectors. For example, in the IDE, it
will place error markers into the source editor, and in a build
system, it may write warnings to the console or generate a report or
even fail the build.
* Handling I/O. Detectors should never read files from disk directly.
This allows lint checks to work smoothly in for example the IDE. When
lint runs on the fly, and a lint check asks for the source file
contents (or other supporting files), the `LintClient` in the IDE
will implement the `readFile` method to first look in the open source
editors and if the requested file is being edited, it will return the
current (often unsaved!) contents.
* Handling network traffic. Lint checks should never open
URLConnections themselves. By going through the lint API to request
data for a URL, not only can the LintClient for example use any
configured IDE proxy settings which is done in the IntelliJ
integration of lint, but even the lint check's own unit tests can
easily be tested because the special unit test implementation of a
`LintClient` provides a simple way to provide exact responses for
specific URLs:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
lint()
.files(...)
// Set up exactly the expected maven.google.com network output to
// ensure stable version suggestions in the tests
.networkData("https://maven.google.com/master-index.xml", ""
+ "\n"
+ "\n"
+ " "
+ "")
.networkData("https://maven.google.com/com/android/tools/build/group-index.xml", ""
+ "\n"
+ "\n"
+ " \n"
+ "")
.run()
.expect(...)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
And much, much, more. **However, most of the implementation of
`LintClient` is intended for integration of lint itself, and as a check
author you don't need to worry about it.** It's the detector API that
matters, and is also less likely to change than the client API.
!!! Tip
The division between the two halves is not perfect; some classes
do not fit neatly in between the two or historically were put in
the wrong place, so this is a high level design to be aware of but
which is not absolute.
Also,
!!! Warning
Because of the division between two separate packages, which in
retrospect was a mistake, a number of APIs that are only intended
for internal lint usage have been made `public` such that lint's
code in one package can access it from the other. There's normally a
comment explaining that this is for internal use only, but be aware
that just because something is `public` or not `final` it's a good
idea to call or override it.
## Creating an Issue
For information on how to set up the project and to actually publish
your lint checks, see the [sample](example.md.html) and
[publishing](publishing.md.html) chapters.
`Issue` is a final class, so unlike `Detector`, you don't subclass
it, you instantiate it via `Issue.create`.
By convention, issues are registered inside the companion object of the
corresponding detector, but that is not required.
Here's an example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~kotlin linenumbers
class SdCardDetector : Detector(), SourceCodeScanner {
companion object Issues {
@JvmField
val ISSUE = Issue.create(
id = "SdCardPath",
briefDescription = "Hardcoded reference to `/sdcard`",
explanation = """
Your code should not reference the `/sdcard` path directly; \
instead use `Environment.getExternalStorageDirectory().getPath()`.
Similarly, do not reference the `/data/data/` path directly; it \
can vary in multi-user scenarios. Instead, use \
`Context.getFilesDir().getPath()`.
""",
moreInfo = "https://developer.android.com/training/data-storage#filesExternal",
category = Category.CORRECTNESS,
severity = Severity.WARNING,
androidSpecific = true,
implementation = Implementation(
SdCardDetector::class.java,
Scope.JAVA_FILE_SCOPE
)
)
}
...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are a number of things to note here.
On line 4, we have the `Issue.create()` call. We store the issue into a
property such that we can reference this issue both from the
`IssueRegistry`, where we provide the `Issue` to lint, and also in the
`Detector` code where we report incidents of the issue.
Note that `Issue.create` is a method with a lot of parameters (and we
will probably add more parameters in the future). Therefore, it's a
good practice to explicitly include the argument names (and therefore
to implement your code in Kotlin).
The `Issue` provides metadata about a type of problem.
The **`id`** is a short, unique identifier for this issue. By
convention it is a combination of words, capitalized camel case (though
you can also add your own package prefix as in Java packages). Note
that the id is “user visible”; it is included in text output when lint
runs in the build system, such as this:
```shell
src/main/kotlin/test/pkg/MyTest.kt:4: Warning: Do not hardcode "/sdcard/";
use Environment.getExternalStorageDirectory().getPath() instead [SdCardPath]
val s: String = "/sdcard/mydir"
-------------
0 errors, 1 warnings
```
(Notice the `[SdCardPath]` suffix at the end of the error message.)
The reason the id is made known to the user is that the ID is how
they'll configure and/or suppress issues. For example, to suppress the
warning in the current method, use
```
@Suppress("SdCardPath")
```
(or in Java, @SuppressWarnings). Note that there is an IDE quickfix to
suppress an incident which will automatically add these annotations, so
you don't need to know the ID in order to be able to suppress an
incident, but the ID will be visible in the annotation that it
generates, so it should be reasonably specific.
Also, since the namespace is global, try to avoid picking generic names
that could clash with others, or seem to cover a larger set of issues
than intended. For example, “InvalidDeclaration” would be a poor id
since that can cover a lot of potential problems with declarations
across a number of languages and technologies.
Next, we have the **`briefDescription`**. You can think of this as a
"category report header“; this is a static description for all
incidents of this type, so it cannot include any specifics. This string
is used for example as a header in HTML reports for all incidents of
this type, and in the IDE, if you open the Inspections UI, the various
issues are listed there using the brief descriptions.
The **`explanation`** is a multi line, ideally multi-paragraph
explanation of what the problem is. In some cases, the problem is self
evident, as in the case of ”Unused declaration“, but in many cases, the
issue is more subtle and might require additional explanation,
particularly for what the developer should **do** to address the
problem. The explanation is included both in HTML reports and in the
IDE inspection results window.
Note that even though we're using a raw string, and even though the
string is indented to be flush with the rest of the issue registration
for better readability, we don't need to call `trimIndent()` on
the raw string. Lint does that automatically.
However, we do need to add line continuations -- those are the trailing
\'s at the end of the lines.
Note also that we have a Markdown-like simple syntax, described in the
"TextFormat” section below. You can use asterisks for italics or double
asterisks for bold, you can use apostrophes for code font, and so on.
In terminal output this doesn't make a difference, but the IDE,
explanations, incident error messages, etc, are all formatted using
these styles.
The **`category`** isn't super important; the main use is that category
names can be treated as id's when it comes to issue configuration; for
example, a user can turn off all internationalization issues, or run
lint against only the security related issues. The category is also
used for locating related issues in HTML reports. If none of the
built-in categories are appropriate you can also create your own.
The **`severity`** property is very important. An issue can be either a
warning or an error. These are treated differently in the IDE (where
errors are red underlines and warnings are yellow highlights), and in
the build system (where errors can optionally break the build and
warnings do not). There are some other severities too; ”fatal“ is like
error except these checks are designated important enough (and have
very few false positives) such that we run them during release builds,
even if the user hasn't explicitly run a lint target. There's also
"informational” severity, which is only used in one or two places, and
finally the “ignore” severity. This is never the severity you register
for an issue, but it's part of the severities a developer can configure
for a particular issue, thereby turning off that particular check.
You can also specify a **`moreInfo`** URL which will be included in the
issue explanation as a “More Info” link to open to read more details
about this issue or underlying problem.
## TextFormat
All error messages and issue metadata strings in lint are interpreted
using simple Markdown-like syntax:
Raw text format | Renders To
-----------------------------|--------------------------
This is a \`code symbol\` | This is a `code symbol`
This is `*italics*` | This is *italics*
This is `**bold**` | This is **bold**
http://, https:// | [](http://), [](https://)
`\*not italics*` | `\*not italics*`
\`\`\`language\n text\n\`\`\`| (preformatted text block)
[Supported markup in lint's markdown-like raw text format]
This is useful when error messages and issue explanations are shown in
HTML reports generated by Lint, or in the IDE, where for example the
error message tooltips will use formatting.
In the API, there is a `TextFormat` enum which encapsulates the
different text formats, and the above syntax is referred to as
`TextFormat.RAW`; it can be converted to `.TEXT` or `.HTML` for
example, which lint does when writing text reports to the console or
HTML reports to files respectively. As a lint check author you don't
need to know this (though you can for example with the unit testing
support decide which format you want to compare against in your
expected output), but the main point here is that your issue's brief
description, issue explanation, incident report messages etc, should
use the above “raw” syntax. Especially the first conversion; error
messages often refer to class names and method names, and these should
be surrounded by apostrophes.
See the [error message](messages.md.html) chapter for more information
on how to craft error messages.
## Issue Implementation
The last issue registration property is the **`implementation`**. This
is where we glue our metadata to our specific implementation of an
analyzer which can find instances of this issue.
Normally, the `Implementation` provides two things:
* The `.class` for our `Detector` which should be instantiated. In the
code sample above it was `SdCardDetector`.
* The `Scope` that this issue's detector applies to. In the above
example it was `Scope.JAVA_FILE`, which means it will apply to Java
and Kotlin files.
## Scopes
The `Implementation` actually takes a **set** of scopes; we still refer
to this as a “scope”. Some lint checks want to analyze multiple types
of files. For example, the `StringFormatDetector` will analyze both the
resource files declaring the formatting strings across various locales,
as well as the Java and Kotlin files containing `String.format` calls
referencing the formatting strings.
There are a number of pre-defined sets of scopes in the `Scope`
class. `Scope.JAVA_FILE_SCOPE` is the most common, which is a
singleton set containing exactly `Scope.JAVA_FILE`, but you
can always create your own, such as for example
```
EnumSet.of(Scope.CLASS_FILE, Scope.JAVA_LIBRARIES)
```
When a lint issue requires multiple scopes, that means lint will
**only** run this detector if **all** the scopes are available in the
running tool. When lint runs a full batch run (such as a Gradle lint
target or a full “Inspect Code“ in the IDE), all scopes are available.
However, when lint runs on the fly in the editor, it only has access to
the current file; it won't re-analyze *all* files in the project for
every few keystrokes. So in this case, the scope in the lint driver
only includes the current source file's type, and only lint checks
which specify a scope that is a subset would run.
This is a common mistake for new lint check authors: the lint check
works just fine as a unit test, but they don't see working in the IDE
because the issue implementation requests multiple scopes, and **all**
have to be available.
Often, a lint check looks at multiple source file types to work
correctly in all cases, but it can still identify *some* problems given
individual source files. In this case, the `Implementation` constructor
(which takes a vararg of scope sets) can be handed additional sets of
scopes, called ”analysis scopes“. If the current lint client's scope
matches or is a subset of any of the analysis scopes, then the check
will run after all.
## Registering the Issue
Once you've created your issue, you need to provide it from
an `IssueRegistry`.
Here's an example `IssueRegistry`:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~kotlin linenumbers
package com.example.lint.checks
import com.android.tools.lint.client.api.IssueRegistry
import com.android.tools.lint.client.api.Vendor
import com.android.tools.lint.detector.api.CURRENT_API
class SampleIssueRegistry : IssueRegistry() {
override val issues = listOf(SdCardDetector.ISSUE)
override val api: Int
get() = CURRENT_API
// works with Studio 4.1 or later; see
// com.android.tools.lint.detector.api.Api / ApiKt
override val minApi: Int
get() = 8
// Requires lint API 30.0+; if you're still building for something
// older, just remove this property.
override val vendor: Vendor = Vendor(
vendorName = "Android Open Source Project",
feedbackUrl = "https://com.example.lint.blah.blah",
contact =<EMAIL_ADDRESS>)
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On line 8, we're returning our issue. It's a list, so an
`IssueRegistry` can provide multiple issues.
The **`api`** property should be written exactly like the way it
appears above in your own issue registry as well; this will record
which version of the lint API this issue registry was compiled against
(because this references a static final constant which will be copied
into the jar file instead of looked up dynamically when the jar is
loaded).
The **`minApi`** property records the oldest lint API level this check
has been tested with.
Both of these are used at issue loading time to make sure lint checks
are compatible, but in recent versions of lint (7.0) lint will more
aggressively try to load older detectors even if they have been
compiled against older APIs since there's a high likelihood that they
will work (it checks all the lint APIs in the bytecode and uses
reflection to verify that they're still there).
The **`vendor`** property is new as of 7.0, and gives lint authors a
way to indicate where the lint check came from. When users use lint,
they're running hundreds and hundreds of checks, and sometimes it's not
clear who to contact with requests or bug reports. When a vendor has
been specified, lint will include this information in error output and
reports.
The last step towards making the lint check available is to make
the `IssueRegistry` known via the service loader mechanism.
Create a file named exactly
```
src/main/resources/META-INF/services/com.android.tools.lint.client.api.IssueRegistry
```
with the following contents (but where you substitute in your own
fully qualified class name for your issue registry):
```
com.example.lint.checks.SampleIssueRegistry
```
If you're not building your lint check using Gradle, you may not want
the `src/main/resources` prefix; the point is that your packaging of
the jar file should contain `META-INF/services/` at the root of the jar
file.
## Implementing a Detector: Scanners
We've finally come to the main task with writing a lint check:
implementing the **`Detector`**.
Here's a trivial one:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~kotlin linenumbers
class MyDetector : Detector() {
override fun run(context: Context) {
context.report(ISSUE, Location.create(context.file),
"I complain a lot")
}
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This will just complain in every single file. Obviously, no real lint
detector does this; we want to do some analysis and **conditionally** report
incidents. For information about how to phrase error messages, see the [error
message](messages.md.html) chapter.
In order to make it simpler to perform analysis, Lint has dedicated
support for analyzing various file types. The way this works is that
you register interest, and then various callbacks will be invoked.
For example:
* When implementing **`XmlScanner`**, in an XML element you can be
called back
- when any of a set of given tags are declared (`visitElement`)
- when any of a set of named attributes are declared
(`visitAttribute`)
- and you can perform your own document traversal via `visitDocument`
* When implementing **`SourceCodeScanner`**, in Kotlin and Java files
you can be called back
- When a method of a given name is invoked (`getApplicableMethodNames`
and `visitMethodCall`)
- When a class of the given type is instantiated
(`getApplicableConstructorTypes` and `visitConstructor`)
- When a new class is declared which extends (possibly indirectly)
a given class or interface (`applicableSuperClasses` and
`visitClass`)
- When annotated elements are referenced or combined
(`applicableAnnotations` and `visitAnnotationUsage`)
- When any AST nodes of given types appear (`getApplicableUastTypes`
and `createUastHandler`)
* When implementing a **`ClassScanner`**, in `.class` and `.jar` files
you can be called back
- when a method is invoked for a particular owner
(`getApplicableCallOwners` and `checkCall`
- when a given bytecode instruction occurs
(`getApplicableAsmNodeTypes` and `checkInstruction`)
- like with XmlScanner's `visitDocument`, you can perform your own
ASM bytecode iteration via `checkClass`.
* There are various other scanners too, for example `GradleScanner`
which lets you visit `build.gradle` and `build.gradle.kts` DSL
closures, `BinaryFileScanner` which visits resource files such as
webp and png files, and `OtherFileScanner` which lets you visit
unknown files.
!!! Note
Note that `Detector` already implements empty stub methods for all
of these interfaces, so if you for example implement
`SourceFileScanner` in your detector, you don't need to go and add
empty implementations for all the methods you aren't using.
!!! Tip
None of Lint's APIs require you to call `super` when you override
methods; methods meant to be overridden are always empty so the
super-call is superfluous.
## Detector Lifecycle
Detector registration is done by detector class, not by detector
instance. Lint will instantiate detectors on your behalf. It will
instantiate the detector once per analysis, so you can stash state on
the detector in fields and accumulate information for analysis at the
end.
There are some callbacks both before each individual file is analyzed
(`beforeCheckFile` and `afterCheckFile`), as well as before and after
analysis of all the modules (`beforeCheckRootProject` and
`afterCheckRootProject`).
This is for example how the ”unused resources“ check works: we store
all the resource declarations and resource references we find in the
project as we process each file, and then in the
`afterCheckRootProject` method we analyze the resource graph and
compute any resource declarations that are not reachable in the
reference graph, and then we report each of these as unused.
## Scanner Order
Some lint checks involve multiple scanners. This is pretty common in
Android, where we want to cross check consistency between data in
resource files with the code usages. For example, the `String.format`
check makes sure that the arguments passed to `String.format` match the
formatting strings specified in all the translation XML files.
Lint defines an exact order in which it processes scanners, and within
scanners, data. This makes it possible to write some detectors more
easily because you know that you'll encounter one type of data before
the other; you don't have to handle the opposite order. For example, in
our `String.format` example, we know that we'll always see the
formatting strings before we see the code with `String.format` calls,
so we can stash the formatting strings in a map, and when we process
the formatting calls in code, we can immediately issue reports; we
don't have to worry about encountering a formatting call for a
formatting string we haven't processed yet.
Here's lint's defined order:
1. Android Manifest
2. Android resources XML files (alphabetical by folder type, so for
example layouts are processed before value files like translations)
3. Kotlin and Java files
4. Bytecode (local `.class` files and library `.jar` files)
5. TOML files
6. Gradle files
7. Other files
8. ProGuard files
9. Property Files
Similarly, lint will always process libraries before the modules
that depend on them.
!!! Tip
If you need to access something from later in the iteration order,
and it's not practical to store all the current data and instead
handle it when the later data is encountered, note that lint has
support for ”multi-pass analysis“: it can run multiple times over
the data. The way you invoke this is via
`context.driver.requestRepeat(this, …)`. This is actually how the
unused resource analysis works. Note however that this repeat is
only valid within the current module; you can't re-run the analysis
through the whole dependency graph.
## Implementing a Detector: Services
In addition to the scanners, lint provides a number of services
to make implementation simpler. These include
* **`ConstantEvaluator`**: Performs evaluation of AST expressions, so
for example if we have the statements `x = 5; y = 2 * x`, the
constant evaluator can tell you that y is 10. This constant evaluator
can also be more permissive than a compiler's strict constant
evaluator; e.g. it can return concatenated strings where not all
parts are known, or it can use non-final initial values of fields.
This can help you find *possible* bugs instead of *certain* bugs.
* **`TypeEvaluator`**: Attempts to provide the concrete type of an
expression. For example, for the Java statements `Object s = new
StringBuilder(); Object o = s`, the type evaluator can tell you that
the type of `o` at this point is really `StringBuilder`.
* **`JavaEvaluator`**: Despite the unfortunate older name, this service
applies to both Kotlin and Java, and can for example provide
information about inheritance hierarchies, class lookup from fully
qualified names, etc.
* **`DataFlowAnalyzer`**: Data flow analysis within a method.
* For Android analysis, there are several other important services,
like the `ResourceRepository` and the `ResourceEvaluator`.
* Finally, there are a number of utility methods; for example there is
an `editDistance` method used to find likely typos used by a number
of checks.
## Scanner Example
Let's create a `Detector` using one of the above scanners,
`XmlScanner`, which will look at all the XML files in the project and
if it encounters a `` tag it will report that `` should
be used instead:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~kotlin linenumbers
import com.android.tools.lint.detector.api.Detector
import com.android.tools.lint.detector.api.Detector.XmlScanner
import com.android.tools.lint.detector.api.Location
import com.android.tools.lint.detector.api.XmlContext
import org.w3c.dom.Element
class MyDetector : Detector(), XmlScanner {
override fun getApplicableElements() = listOf("bitmap")
override fun visitElement(context: XmlContext, element: Element) {
val incident = Incident(context, ISSUE)
.message( "Use `` instead of ``")
.at(element)
context.report(incident))
}
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The above is using the new `Incident` API from Lint 7.0 and on; in
older versions you can use the following API, which still works in 7.0:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~kotlin linenumbers
class MyDetector : Detector(), XmlScanner {
override fun getApplicableElements() = listOf("bitmap")
override fun visitElement(context: XmlContext, element: Element) {
context.report(ISSUE, context.getLocation(element),
"Use `` instead of ``")
}
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The second, older form, may seem simpler, but the new API allows a lot
more metadata to be attached to the report, such as an override
severity. You don't have to convert to the builder syntax to do this;
you could also have written the second form as
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~kotlin linenumbers
context.report(Incident(ISSUE, context.getLocation(element),
"Use `` instead of ``"))
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
## Analyzing Kotlin and Java Code
### UAST
To analyze Kotlin and Java code, lint offers an abstract syntax tree,
or ”AST“, for the code.
This AST is called ”UAST“, for ”Universal Abstract Syntax Tree“, which
represents multiple languages in the same way, hiding the language
specific details like whether there is a semicolon at the end of the
statements or whether the way an annotation class is declared is as
`@interface` or `annotation class`, and so on.
This makes it possible to write a single analyzer which works
(”universally“) across all languages supported by UAST. And this is
very useful; most lint checks are doing something API or data-flow
specific, not something language specific. If however you do need to
implement something very language specific, see the next section,
"PSI”.
In UAST, each element is called a **`UElement`**, and there are a
number of subclasses -- `UFile` for the compilation unit, `UClass` for
a class, `UMethod` for a method, `UExpression` for an expression,
`UIfExpression` for an `if`-expression, and so on.
Here's a visualization of an AST in UAST for two equivalent programs
written in Kotlin and Java. These programs both result in the same
AST, shown on the right: a `UFile` compilation unit, containing
a `UClass` named `MyTest`, containing `UField` named s which has
an initializer setting the initial value to `hello`.
************************************************************************
*
* MyTest.kt: UAST:
* +---------------------------+ .-------.
* | package test.pkg | | UFile |
* | class MyTest { | '---+---'
* | private val s = “hello” | |
* | } | .------+------.
* +---------------------------+ | UClass MyTest |
* '------+------'
* MyTest.java: |
* +------------------------+ .---+----.
* | package test.pkg; | | UField s |
* | public class MyTest { | '+------+'
* | private String s = | / \
* | “hello”; | / \
* | } | / \
* +------------------------+ / \
* .-----------+. .--------+---------------.
* |UIdentifier s | | ULiteralExpression hello |
* '------------' '------------------------'
*
************************************************************************
!!! Tip
The name “UAST” is a bit misleading; it is not some sort of superset
of all possible syntax trees; instead, think of this as the “Java
view” of all code. So, for example, there isn’t a `UProperty` node
which represents Kotlin properties. Instead, the AST will look the
same as if the property had been implemented in Java: it will
contain a private field and a public getter and a public setter
(unless of course the Kotlin property specifies a private setter).
If you’ve written code in Kotlin and have tried to access that
Kotlin code from a Java file you will see the same thing -- the
“Java view” of Kotlin. The next section, “PSI“, will discuss how to
do more language specific analysis.
### UAST Example
Here's an example (from the built-in `AlarmDetector` for Android) which
shows all of the above in practice; this is a lint check which makes
sure that if anyone calls `AlarmManager.setRepeating`, the second
argument is at least 5,000 and the third argument is at least 60,000.
Line 1 says we want to have line 3 called whenever lint comes across a
method to `setRepeating`.
On lines 8-4 we make sure we're talking about the correct method on the
correct class with the correct signature. This uses the `JavaEvaluator`
to check that the called method is a member of the named class. This is
necessary because the callback would also be invoked if lint came
across a method call like `Unrelated.setRepeating`; the
`visitMethodCall` callback only matches by name, not receiver.
On line 36 we use the `ConstantEvaluator` to compute the value of each
argument passed in. This will let this lint check not only handle cases
where you're specifying a specific value directly in the argument list,
but also for example referencing a constant from elsewhere.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~kotlin linenumbers
override fun getApplicableMethodNames(): List = listOf("setRepeating")
override fun visitMethodCall(
context: JavaContext,
node: UCallExpression,
method: PsiMethod
) {
val evaluator = context.evaluator
if (evaluator.isMemberInClass(method, "android.app.AlarmManager") &&
evaluator.getParameterCount(method) == 4
) {
ensureAtLeast(context, node, 1, 5000L)
ensureAtLeast(context, node, 2, 60000L)
}
}
private fun ensureAtLeast(
context: JavaContext,
node: UCallExpression,
parameter: Int,
min: Long
) {
val argument = node.valueArguments[parameter]
val value = getLongValue(context, argument)
if (value < min) {
val message = "Value will be forced up to $min as of Android 5.1; " +
"don't rely on this to be exact"
context.report(ISSUE, argument, context.getLocation(argument), message)
}
}
private fun getLongValue(
context: JavaContext,
argument: UExpression
): Long {
val value = ConstantEvaluator.evaluate(context, argument)
if (value is Number) {
return value.toLong()
}
return java.lang.Long.MAX_VALUE
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
### Looking up UAST
To write your detector's analysis, you need to know what the AST for
your code of interest looks like. Instead of trying to figure it out by
examining the elements under a debugger, a simple way to find out is to
”pretty print“ it, using the `UElement` extension method
**`asRecursiveLogString`**.
For example, given the following unit test:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
lint().files(
kotlin(""
+ "package test.pkg\n"
+ "\n"
+ "class MyTest {\n"
+ " val s: String = \"hello\"\n"
+ "}\n"), ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you evaluate `context.uastFile?.asRecursiveLogString()` from
one of the callbacks, it will print this:
```text
UFile (package = test.pkg)
UClass (name = MyTest)
UField (name = s)
UAnnotation (fqName = org.jetbrains.annotations.NotNull)
ULiteralExpression (value = "hello")
UAnnotationMethod (name = getS)
UAnnotationMethod (name = MyTest)
```
(This also illustrates the earlier point about UAST representing the
Java view of the code; here the read-only public Kotlin property ”s“ is
represented by both a private field `s` and a public getter method,
`getS()`.)
### Resolving
When you have a method call, or a field reference, you may want to take
a look at the called method or field. This is called ”resolving“, and
UAST supports it directly; on a `UCallExpression` for example, call
`.resolve()`, which returns a `PsiMethod`, which is like a `UMethod`,
but may not represent a method we have source for (which for example
would be the case if you resolve a reference to the JDK or to a library
we do not have sources for). You can call `.toUElement()` on the
PSI element to try to convert it to UAST if source is available.
!!! Warning
Resolving only works if lint has a correct classpath such that the
referenced method, field or class are actually present. If it is
not, resolve will return null, and various lint callbacks will not
be invoked. This is a common source of questions for lint checks
”not working“; it frequently comes up in lint unit tests where a
test file will reference some API that isn't actually included in
the class path. The recommended approach for this is to declare
local stubs. See the [unit testing](unit-testing.md.html) chapter
for more details about this.
### Implicit Calls
Kotlin supports operator overloading for a number of built-in
operators. For example, if you have the following code,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fun test(n1: BigDecimal, n2: BigDecimal) {
// Here, this is really an infix call to BigDecimal#compareTo
if (n1 < n2) {
...
}
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the `<` here is actually a function call (which you can verify by
invoking Go To Declaration over the symbol in the IDE). This is not
something that is built specially for the `BigDecimal` class; this
works on any of your Java classes as well, and Kotlin if you put the
`operator` modifier as part of the function declaration.
However, note that in the abstract syntax tree, this is **not**
represented as a `UCallExpression`; here we'll have a
`UBinaryExpression` with left operand `n1`, right operand `n2` and
operator `UastBinaryOperator.LESS`. This means that if your lint check
is specifically looking at `compareTo` calls, you can't just visit
every `UCallExpression`; you *also* have to visit every
`UBinaryExpression`, and check whether it's invoking a `compareTo`
method.
This is not just specific to binary operators; it also applies to unary
operators (such as `!`, `-`, `++`, and so on), as well as even array
accesses; an array access can map to a `get` call or a `set` call
depending on how it's used.
Lint has some special support to help handle these situations.
First, the built-in support for call callbacks (where you register an
interest in call names by returning names from the
`getApplicableMethodNames` and then responding in the `visitMethodCall`
callback) already handles this automatically. If you register for
example an interest in method calls to `compareTo`, it will invoke your
callback for the binary operator scenario shown above as well, passing
you a call which has the right value arguments, method name, and so on.
The way this works is that lint can create a ”wrapper“ class which
presents the underlying `UBinaryExpression` (or
`UArrayAccessExpression` and so on) as a `UCallExpression`. In the case
of a binary operator, the value parameter list will be the left and
right operands. This means that your code can just process this as if
the code had written as an explicit call instead of using the operator
syntax. You can also directly look for this wrapper class,
`UImplicitCallExpression`, which has an accessor method for looking up
the original or underlying element. And you can construct these
wrappers yourself, via `UBinaryExpression.asCall()`,
`UUnaryExpression.asCall()`, and `UArrayAccessExpression.asCall()`.
There is also a visitor you can use to visit call calls --
`UastCallVisitor`, which will visit all calls, including those from
array accesses and unary operators and binary operators.
This support is particularly useful for array accesses, since unlike
the operator expression, there is no `resolveOperator` method on
`UArrayExpression`. There is an open request for that in the UAST issue
tracker (KTIJ-18765), but for now, lint has a workaround to handle the
resolve on its own.
### PSI
PSI is short for ”Program Structure Interface“, and is IntelliJ's AST
abstraction used for all language modeling in the IDE.
Note that there is a **different** PSI representation for each
language. Java and Kotlin have completely different PSI classes
involved. This means that writing a lint check using PSI would involve
writing a lot of logic twice; once for Java, and once for Kotlin. (And
the Kotlin PSI is a bit trickier to work with.)
That's what UAST is for: there's a ”bridge“ from the Java PSI to UAST
and there's a bridge from the Kotlin PSI to UAST, and your lint check
just analyzes UAST.
However, there are a few scenarios where we have to use PSI.
The first, and most common one, is listed in the previous section on
resolving. UAST does not completely replace PSI; in fact, PSI leaks
through in part of the UAST API surface. For example,
`UMethod.resolve()` returns a `PsiMethod`. And more importantly,
`UMethod` **extends** `PsiMethod`.
!!! Warning
For historical reasons, `PsiMethod` and other PSI classes contain
some unfortunate APIs that only work for Java, such as asking for
the method body. Because `UMethod` extends `PsiMethod`, you might be
tempted to call `getBody()` on it, but this will return null from
Kotlin. If your unit tests for your lint check only have test cases
written in Java, you may not realize that your check is doing the
wrong thing and won't work on Kotlin code. It should call `uastBody`
on the `UMethod` instead. Lint's special detector for lint detectors
looks for this and a few other scenarios (such as calling `parent`
instead of `uastParent`), so be sure to configure it for your
project.
When you are dealing with ”signatures“ -- looking at classes and
class inheritance, methods, parameters and so on -- using PSI is
fine -- and unavoidable since UAST does not represent bytecode
(though in the future it potentially could, via a decompiler)
or any other JVM languages than Kotlin and Java.
However, if you are looking at anything *inside* a method or class
or field initializer, you **must** use UAST.
The **second** scenario where you may need to use PSI is where you have
to do something language specific which is not represented in UAST. For
example, if you are trying to look up the names or default values of a
parameter, or whether a given class is a companion object, then you'll
need to dip into Kotlin PSI.
There is usually no need to look at Java PSI since UAST fully covers
it, unless you want to look at individual details like specific
whitespace between AST nodes, which is represented in PSI but not UAST.
!!! Tip
You can find additional documentation from JetBrains for both
[PSI](https://plugins.jetbrains.com/docs/intellij/psi.html) and
[UAST](https://plugins.jetbrains.com/docs/intellij/uast.html).
Just note that their documentation is aimed at IDE plugin developers
rather than lint developers.
## Testing
Writing unit tests for the lint check is important, and this is covered
in detail in the dedicated [unit testing](unit-testing.md.html)
chapter.


About me
My name is Steven Jones and I am a full-stack Web Developer student at DeltaV Code School, currently living in Cedar Falls, IA. I have a Bachelor of Science in Computer Information Systems from Gallaudet University, and my primary focus and inspiration for my studies is Web Development. In my free time, I study user interface and practices on Javascript codes. I am both driven and self-motivated, and I am constantly experimenting with new technologies and techniques. I am very passionate about Web Development, and strive to better myself as a developer, and the development community as a whole.
I moved to Iowa in 2018 from Colorado. Reason I see lot of opportunity in Iowa for full stack development. Also I found a best school for full stack development bootcamp in Cedar Rapids, Iowa.
“The Rockies are therefore very young and should never be thought of as ancient. They are still in the process of building and eroding, and no one today can calculate what they will look like ten million years from now. They have the extravagant beauty of youth, the allure of adolescence, and they are mountains to be loved.”
― James A. Michener, Centennial
- Discipline is the bridge between goals and accomplishment.
- My personal goals are to be happy, healthy and to be surrounded by loved ones.
- A creative man is motivated by the desire to achieve, not by the desire to beat others.


Congress protests against electoral bonds on the Parliament premises
The issue of electoral bonds has snowballed into a political flash point following reports that the Reserve Bank of India and the Election Commission had reservations against them.
by PTIThe Congress on November 22 stepped up its attack on the Centre over electoral bonds, alleging that the government is a “factory of lies” and demanded that Prime Minister Narendra Modi break his silence over the issue.
Several senior Congress leaders, including Leader of Opposition in Rajya Sabha Ghulam Nabi Azad, Congress’ leader in Lok Sabha Adhir Ranjan Chowdhury, Anand Sharma, Shashi Tharoor and Manish Tewari, protested against the government inside Parliament House premises.
The issue of electoral bonds has snowballed into a political flash point following reports that the Reserve Bank of India and the Election Commission had reservations against them, but were overruled by the Modi government.
Congress’s chief spokesperson Randeep Surjewala, in a tweet, cited a media report that claimed that the government made SBI accept expired electoral bonds sold in illegal window, and alleged that the government was a “factory of lies”.


NAME
zip_set_archive_comment —
set zip
archive comment
LIBRARY
libzip (-lzip)
SYNOPSIS
#include <zip.h>
int
zip_set_archive_comment(
zip_t
*archive,
const char
*comment,
zip_uint16_t
len);
DESCRIPTION
The
zip_set_archive_comment() function sets the comment for
the entire zip archive. If
comment is
NULL
and
len is 0, the archive
comment will be removed.
comment must be encoded in
ASCII or UTF-8.
RETURN VALUES
Upon successful completion 0 is returned. Otherwise, -1 is returned and the
error information in
archive is set to indicate the
error.
ERRORS
zip_set_archive_comment() fails if:
-
-
- [
ZIP_ER_INVAL
]
- len is less than 0 or longer than the
maximum comment length in a zip file (65535), or
comment is not a valid UTF-8 encoded string.
-
-
- [
ZIP_ER_MEMORY
]
- Required memory could not be allocated.
SEE ALSO
libzip(3),
zip_get_archive_comment(3),
zip_get_file_comment(3),
zip_set_file_comment(3)
HISTORY
zip_set_archive_comment() was added in libzip 0.7. In libzip
0.11 the type of
len was changed from
int to
zip_uint16_t.
AUTHORS
Dieter Baron
<
<EMAIL_ADDRESS>and
Thomas Klausner
<
tk@giga.or.at>


STICKY FINGERS A film review by Jeff Meyer Copyright 1988 Jeff Meyer
STICKY FINGERS (United States, 1988) Director: Catlin Adams Screenwriters: Catlin Adams, Melanie Mayron Cast: Helen Slater, Melanie Mayron, Danitra Vance, Eilleen Brennan, Carol Kane, Christopher Guest, Stephen McHattie
Well, what can I say? These two musicians (Slater and Mayron [the latter also co-wrote the film]) are living hand-to-mouth in New York as park performers, going through various romantic tribulations (McHattie and Guest) and avoiding their landlord (Brennan). A drug-dealing friend asks the pair to keep an eye on a bag while she's out of town. Of course, they decide to open it and find that it's full of money. $900,000 worth. Of course, they initially want nothing to do with it, but....look, do I have to draw you a picture?
Mayron and Catlin Adams showed up after the showing, and everyone was very polite, which is never a good sign. They said they had wanted to do a "Laurel and Hardy" type film; at times, I thought it was a Lucy and Ethel comedy, as Slater and Mayron tend to look at each other and go "WAAAAHH!" throughout the picture. Sorry, but give me SONS OF THE DESERT any time.
There are a couple of performances that do stay above water -- you'd expect it with such a good cast. There is something about Carol Kane that makes me grin idiotically whenever she's on; here, she plays here a ditzy Southern woman bit as Brennan's sister, in New York to help Brennan recuperate from broken legs. Her romantic dalliance with the parking lot attendant next door is really good. Danitra Vance, one of the best Ebersol-produced SATURDAY NIGHT LIVE performers of the early 80s, does a nice job as the girls' rational musician friend. And Mayron, who is a favorite of mine on the TV program THIRTY-SOMETHING, is appealing in her quiet moments; it's a pity she didn't bring the writers from the show onto this project. Christopher Guest, one of the best comic performers of the last decade, isn't given anything to be use, and ends up being rather dull.
SUMMARY: Slapstick and shopping humor, all having the general humorous composition of soggy cardboard. There's better things out there, gang...
LINER NOTES: Sorry these are taking so long to get out -- STICKY FINGERS was shown a week ago, and is already out in the theaters. I'm just now catching up with the reviews. Observations so far: seen quite a few films, though I avoided IT'S ALIVE III on the basis of the lateness of the hour, IGUANA because the showing at the Secret Festival (which I can't tell you about, sorry) was so disturbing that I went home and read for the rest of the day, and A KILLING AFFAIR on the recommendation of Peter Reiher. Good films so far, and one GREAT film: DOMINICK AND EUGENE, which is out in theaters already.
Moriarty, aka Jeff Meyer INTERNET<EMAIL_ADDRESS>Manual UUCP: {uw-beaver, sun, microsoft}!fluke!moriarty
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


RBI supersedes board of DHFL over governance concerns
by Furquan MoharkanThe Reserve Bank of India on Wednesday has superseded the board of embattled Dewan Housing Finance Corporation over the governance concerns and multiple defaults by the shadow bank.
“The Reserve Bank has today superseded the Board of Directors of Dewan Housing Finance Corporation Limited (DHFL) owing to governance concerns and defaults by DHFL in meeting various payment obligations,” the central bank said in a statement issued on Wednesday.
The Reserve Bank has also appointed R Subramaniakumar, ex-MD and CEO of Indian Overseas Bank as the Administrator for the entity.
The move comes under the powers bestowed upon RBI under Section 45-IE (I) of the Reserve Bank of India Act, 1934.
The company is also likely to go through the insolvency process, which will be initiated by the Reserve Bank of India.
“The Reserve Bank also intends to shortly initiate the process of resolution of the company under the Insolvency and Bankruptcy (Insolvency and Liquidation Proceedings of Financial Service Providers and Application to Adjudicating Authority) Rules, 2019 and would also apply to the NCLT for appointing the Administrator as the Insolvency Resolution Professional,” the central bank said.


Match With A Designer Quiz
Portfolio Review (brand1)
Job Request (brand2)
Networking (brand3)
all types
type1
type2
type3
type4
all colors
red
blue
green
yellow
all sizes
uk-size8
uk-size9
uk-size10
uk-size11
Results


About Us
Who am I and why did I decide to use this topic?
Who am I?
My name is Jordan and this is my website about why I think it is better to live in New York rather than in Florida. Since 2017, I've spent my winter and summer breaks living in Fort Lauderdale which is located 30 minutes away from Miami in South Florida. Don't get me wrong, from jet skiing along the coastline to snorkeling down in the keys to going to Disney World, there are some fun things to do in Florida; but it will still never be able to compare to the one and only New York City.
Why did I decide to use this topic?
I decided to use my website to talk about this matter because I feel like it is important to know the facts to prove why I think New York is the better living situation even though some New Yorkers are moving to various parts of Florida. Another reason why I chose this is because I just came back to New York after spending seven boring weeks of my life doing the same things repeatedlty in Southern Florida and I want to inform people that the Florida they advertise isn't the same Florida you see when you actually go there.
Throught this website I will be comparing and contrasting the difference between New York and Florida's:
- Weather
- Housing
- Places to eat
- Things to do
- Transportation


Inbytes
All the details
Contact the Bride and Groom
RSVP
HOPE YOU CAN MAKE IT!
Kindly Respond By March, 2017
RSVP
CAN YOU COME?
We really hope you can make it.
Sincerely, &
Going
Can't come


Creates a group of radio buttons.
This example has not been styled.
Another way to write forms is to use the tag - the form fields are then put inside table cells.
name - the name of the radio buttons / input tags
value - which radio button should be checked when the page loads
label - a text associated with the entire radio button group
labelClass - extra class for the label
focus [0] - should this radio group receive focus when the page loads? (At most one focused field per page)
display - must be one of {inline, block} - if the radio buttons should be displayed on the same row (inline) or one radio
button per line (block). In the CSS example below the default is set to block (last rule).
content - radio tags
value - the value of the radio button - same as the value attribute of the generated input tag.
label - a text associated with this particular radio button
labelClass - extra class for the label
accesskey
checked [0] - same as the "value" attribute of the radioGroup tag
lineBreakAfter [0] - adds a line break after the radio button (if "display" is "inline")
rule - a rule that must be obeyed (see the )
ruleMsg - the text that will be displayed to the user in case the rule wasn't obeyed
In order to look good, for example together with multiple fields or other checkboxes or radio button groups,
the HTML output by radioGroup and radio tags must be styled with CSS, or the tag could be used.
See the tag for example CSS.
The "radio" tag can only exist inside a "radioGroup" tag.
See also and .


Walking alone is inherently more risky then being in a group. Finding a trustworthy group on the fly is inherently difficult.


About StudyGroups
With this web you can share the study time with other students, meeting at the library or at free classrooms in the university. This app is thought to help students that don't want to study alone and create a meeting point for students in your university. You can both create a group, and wait for other students to join you, or you can directly join groups other students have created before. Hope you will enjoy!


Move mouse over a fusion table feature and pause a while (configurable, default < 0.5 sec), a map tip will display.
Select an sample fusion table:
Point
Line
Polygon


The Private Investigations industry can come across as a dark and murky place and many PI firms play up this idea in their branding. Kusic & Kusic is no exception — sometimes that's exactly what the customer is after. What Kusic & Kusic does differently is that for every step taken to play up their image, they make equal effort to educate customers about the private investigations industry and how they keep their surveillance practice ethical.
The home and service pages feature background video from non-investigative ride-alongs and staged surveillance scenarios.
Each category of service features unique video backgrounds that illustrate actual surveillance techniques.
A regularly updated blog features topical news stories, while a 'New Client Advice' matrix suggests questions that potential customers might consider to ask when hiring a Private Investigator.
As many surveillance cases go beyond the limits of the city, a custom Google Map communicates the geographic area the company primarily services.
The Kusic & Kusic site adds useful layer of information to support a brand image that takes its cues from the world of counter-intelligence and secrecy. It offers an abundance of public information about the industry and aims to educate potential clients who are deciding whether or not to engage a private investigator.


Home
About
Product
Blog
Single post
Contact
Order Form
Item
Qty
Each
Total
KIWI
$ 5.95
MANGO
$ 10.95
CANTALOUPE
$ 20.95
Grand Total :


home
Create your Society here
1
Society info
Society name:
Own Real Name:
Owner Cell phone:
Level:
undergraduate
graduate
2
Society profile
Description:
Society Major/Club:
Computer Sicence
Electric Engineer
Chemical Engineer
Bio Engineer
Civil Engineer
Aerospace
Life and Physical Sciences
Humanities
Social Sciences
Art
Nursing
Club
Interests:
Study Resource
Entertainment
career
Course Quarter:
Winter 2015
Spring 2015
Fall 2016
Apply


Undocumented function which provides a complete solution for executing remote threads across session boundaries. It allows any process to inject a DLL into any other process irrespective of session in which it is running as long as it has sufficient privileges.
Limitations
Though NtCreateThreadEx provides a universal solution on Vista+ for remote thread execution, it is risky to use in production code because it is an undocumented function. As things change, testing is necessary before putting in production, especially when injecting code into system critical processes such as LSASS or CSRSS.
Another limitation is that it cannot be used in XP because it was not implemented. It is possible to dynamically use CreateRemoteThread on XP and NtCreateThreadEx on anything newer.
Prototype NtCreateThreadEx function:
typedef NTSTATUS (WINAPI *LPFUN_NtCreateThreadEx)
(
OUT PHANDLE hThread,
IN ACCESS_MASK DesiredAccess,
IN LPVOID ObjectAttributes,
IN HANDLE ProcessHandle,
IN LPTHREAD_START_ROUTINE lpStartAddress,
IN LPVOID lpParameter,
IN BOOL CreateSuspended,
IN ULONG StackZeroBits,
IN ULONG SizeOfStackCommit,
IN ULONG SizeOfStackReserve,
OUT LPVOID lpBytesBuffer
);
Function is almost similar to CreateRemoteThread except the last parameter which takes an unknown buffer structure. Here is the definition of that buffer structure.
//Buffer argument passed to NtCreateThreadEx function
struct NtCreateThreadExBuffer
{
ULONG Size;
ULONG Unknown1;
ULONG Unknown2;
PULONG Unknown3;
ULONG Unknown4;
ULONG Unknown5;
ULONG Unknown6;
PULONG Unknown7;
ULONG Unknown8;
};
This is derived based on reverse engineering work. The above functions can be changed by Microsoft at any time.
Executing Remote Thread into System Process using NtCreateThreadEx
Execution is so similar to CreateRemoteThread function that allocating and copying are not mentioned here.
Need to load NtCreateThreadEx function from Ntdll.dll:
HMODULE modNtDll = GetModuleHandle("ntdll.dll");
if( !modNtDll )
{
printf("\n failed to get module handle for ntdll.dll, Error=0x%.8x", GetLastError());
return;
}
LPFUN_NtCreateThreadEx funNtCreateThreadEx =
(LPFUN_NtCreateThreadEx) GetProcAddress(modNtDll, "NtCreateThreadEx");
if( !funNtCreateThreadEx )
{
printf("\n failed to get funtion address from ntdll.dll, Error=0x%.8x", GetLastError());
return;
}
Now setup the buffer structure which is passed as the last param to NtCreateThreadEx:
//setup and initialize the buffer
NtCreateThreadExBuffer ntbuffer;
memset (&ntbuffer,0,sizeof(NtCreateThreadExBuffer));
DWORD temp1 = 0;
DWORD temp2 = 0;
ntbuffer.Size = sizeof(NtCreateThreadExBuffer);
ntbuffer.Unknown1 = 0x10003;
ntbuffer.Unknown2 = 0x8;
ntbuffer.Unknown3 = &temp2;
ntbuffer.Unknown4 = 0;
ntbuffer.Unknown5 = 0x10004;
ntbuffer.Unknown6 = 4;
ntbuffer.Unknown7 = &temp1;
ntbuffer.Unknown8 = 0;
Finally, execute remote thread 'pRemoteFunction' into remote process using NtCreateThreadEx function. Here one can use LoadLibraryA() function address instead of 'pRemoteFunction' thread to implement 'DLL Injection technique.
NTSTATUS status = funNtCreateThreadEx(
&hThread,
0x1FFFFF,
NULL,
hProcess,
(LPTHREAD_START_ROUTINE) pRemoteFunction,
pRemoteParameter,
FALSE, //start instantly
NULL,
NULL,
NULL,
&ntbuffer
);
Now check for the result of NtCreateThreadEx function and wait for it to execute completely
if (hThread == NULL)
{
printf("\n NtCreateThreadEx failed, Error=0x%.8x", GetLastError());
return;
}
//Wait for thread to complete....
WaitForSingleObject(hThread, INFINITE);
Finally, retrieve the return value from the remote thread function, 'pRemoteFunction' to verify the result of function execution.
'//Check the return code from remote thread function
int dwExitCode;
if( GetExitCodeThread(hThread, (DWORD*) &dwExitCode) )
{
printf("\n Remote thread returned with status = %d", dwExitCode);
}
CloseHandle(hThread);


(Information from Barry Yip<EMAIL_ADDRESS>>,
Norman Diamond, NIIBE Yutaka and H. Peter Anvin, who
contributed the photographs of his
JP106 keyboard above and of his
Japanese laptop.)
Common Japanese keyboards have five additional keys (106-key, or 86-key for a notebook; these days there may also be 3 extra Windows keys). These keys have scancodes 70 (hiragana/katakana), 73 (backslash/underscore), 79 (henkan/zenkouho), 7b (muhenkan), 7d (yen/vertical bar).
| USB | Scancode | Japanese | US | USB | Scancode | Japanese | US | |
| 53 | 29 | (hankaku/zenkaku) | (` / ~) | 47 | 1a | (@ / `) | ([ / {) | |
| 31 | 03 | (2 / ") | (2 / @) | 48 | 1b | ([ / {) | (] / }) | |
| 35 | 07 | (6 / &) | (6 / ^) | 51 | 27 | (; / +) | (; / :) | |
| 36 | 08 | (7 / ') | (7 / &) | 52 | 28 | (: / *) | (' / ") | |
| 37 | 09 | (8 / () | (8 / *) | 29 | 2b | (] / }) | (backslash / |) | |
| 38 | 0a | (9 / )) | (9 / () | 135 | 73 | (backslash / _) | ||
| 39 | 0b | (0 / ~) | (0 / )) | 139 | 7b | (muhenkan) | ||
| 45 | 0c | (- / =) | (- / _) | 138 | 79 | (henkan/zenkouho) | ||
| 46 | 0d | (^ / overbar) | (= / +) | 136 | 70 | (hiragana/katakana) | ||
| 137 | 7d | (\ / |) | ||||||
ASCII and JIS-Roman differ in two or three points: the code positions where ASCII has backslash, tilde, broken bar, JIS-Roman uses yen, overbar and vertical bar, respectively.
Some keyboards have the tilde printed on the keycap for the 0 key, some don't. Similarly, some keyboards have the backslash printed on the keycap for the _ key and some don't, but in all cases you need Shift to get _.
Norman Diamond adds to the previous section:
To the left of the spacebar, (Shift-JIS) 無変換 (muhenkan) means no conversion from kana to kanji. To the right of the spacebar, 変換 (henkan) means conversion from kana to kanji. In Microsoft systems it converts the most recently input sequence of kana to the system's first guess at a string of kanji/kana/etc. with the correct pronunciation and a guess at the meaning. Repeated keypresses change it to other possible guesses which are either less common or less recently used, depending on the situation. The shifted version of this key is 前侯補 (zenkouho) which means "previous candidate" -- "zen" means "previous", while "kouho" means "candidate" (explanation courtesy of NIIBE Yutaka) -- it rotates back to earlier guesses for kanji conversion. The alt version of this key is 全侯補 also pronounced (zenkouho), which means "all candidates" -- here, "zen" means "all" -- it displays a menu of all known guesses. I never use the latter two functions of the key, because after pushing the henkan key about three times and not getting the desired guess, it displays a menu of all known guesses anyway.
Next on the right, ひらがな (hiragana) means that phonetic input uses one conventional Japanese phonetic alphabet, which of course can be converted to kanji by pressing the henkan key later. The shifted version is カタカナ (katakana) which means the other Japanese phonetic alphabet, and the alt version is ローマ字 (ro-maji) which means the Roman alphabet.
Near the upper left, 半/全 (han/zen) means switch between hankaku (half-size, the same size as an ASCII character) and zenkaku (full-size, since the amount of space occupied by a kanji is approximately a square, twice as fat as an ASCII character). It only affects katakana and a few other characters (for example there's a full-width copy of each ASCII character in addition to the single-byte half-width encodings). The alt version of this is 漢字 (kanji) which actually causes typed Roman phonetic keys to be displayed as Japanese phonetic kana (either hiragana or katakana depending on one of the other keys described above) and doesn't cause conversion to kanji.
John Bradford reports that he has a Japanese keyboard (an IBM 5576 KEYBOARD-2, part number 94X1110) that by default simulates US key layout. Thus, pressing the @ key yields scancodes 2a 03 (fake shift followed by digit 2), pressing Shift - yields scancodes b6 0d (fake shift down, =) with release 8d 36, etc.
Thus, the (translated Set 2) scancodes can be read off the table with differences between the Japanese and the US layout.
In this state the non-ASCII keys (Yen and overline) yield an error (ff). The Japanese keys hankaku, kanji/katakana, muhenkan, zenkoho/henkan, hiragana, zenmen ki, yield the codes expected from keys in that position on a US keyboard: 29 (`/~), 38 (LAlt), 39 (space), 39 (space), 39 (space), e0 38 (RAlt), respectively.
Switching the keyboard to Set 3 enables the Japanese keys. In untranslated Set 3 these give codes: hankaku 0e, Yen 13, overline (shift ^), kanji/katakana 19, muhenkan 85, zenkoho/henkan 86, hiragana 87, zenmen ki 39. (Also: backslash/underscore 5c, bracketright/braceright 53.)
This is the only keyboard I know that gives more information in Set 3 than in Set 2. It reports keyboard ID ab 90.


Welcome to the Jobs board
{% for job in jobs %}
{{ job.title }} at {{ job.company }}
{{ job.details }}
{% endfor %}


[viewBag] title = "International Cooperation Department" ==
|
111700, Tashkent region, Chirchik city, A.Temur str. 104<EMAIL_ADDRESS><EMAIL_ADDRESS>+998 (70) 712-45-41; +998 (90) 944-13-58
|
Head of Unit Mukhamedov Mukhriddin |
Department responsibilities:
Major dimensions:
2. Foreign citizens or international students
• systematization of information about foreign students studying at the institute;
• supporting in visa getting and residency process for foreign students, prepare invitations for participants in conferences, etc.
3. Establishment international collaboration and preparation of MOU and agreements with foreign HEIs.
5. Analyze data and statistics on international relations and international activities.
6. Language support correspondence (within the framework of the activities of the international department and at the request of structural units).
7. Doing practical training (English, translation and interpretation) on the basis of the department with students studying in “Foreign language and literature: English” and “Foreign language and literature: German” majors.
8. Organize the meetings and briefings with foreign delegations in the several levels.
Head of International Cooperation Department
Specialists


Base type: System.Entity
| Name | Type | Notes |
|---|---|---|
| UserID | System.Int32 | |
| AccountSID | System.String | |
| AccountName | System.String | |
| FirstName | System.String | |
| LastName | System.String | |
| Alias | System.String | |
| Title | System.String | |
| Department | System.String | |
| Office | System.String | |
| Company | System.String | |
| Manager | System.String | |
| Assistant | System.String | |
| EmailAddressList | System.String | |
| MemberOfList | System.String | |
| Phone | System.String | |
| Address | System.String | |
| City | System.String | |
| State | System.String | |
| ZipCode | System.String | |
| CountryRegion | System.String | |
| PrimaryGroup | System.String | |
| DisplayName | System.String | |
| Description | System.String | |
| InstanceType | System.Type | |
| Uri | System.String | |
| InstanceSiteId | System.Int32 | Default='0'. |
| IPAddresses | Orion.UDT.UserToIPAddressCurrent | Defined by relationship Orion.UDT.UserToIPAddressReferencesUser (System.Reference) |
| IPAddressesHistory | Orion.UDT.UserToIPAddressHistory | Defined by relationship Orion.UDT.UserToIPAddressHistoryReferencesUser (System.Reference) |


Nyzo version 507 (commit on GitHub) corrects an issue with in-cycle node identifier updates.
This version modifies code used by the verifier only. The sentinel is indirectly affected, however, as updating a verifier will allow it to provide more accurate information to sentinels. This is a minor update, and it can be skipped if you find it uninteresting.
The NodeManager class limits how frequently verifier identifiers can be changed for an IP. If frequent IP changes were allowed, a small number of IP addresses could be used to support a larger number of verifiers by frequently cycling IP addresses. This protection, though, was incorrectly disallowing all identifier changes of IP addresses assigned to in-cycle identifiers.
In the NodeManager class, the verifierChangeAllowed() method determines whether an update of the identifier for an IP address is permitted. Previously, this method referenced the queue timestamp of the verifier. This has been changed to reference a new field, identifierChangeTimestamp.
This new field was necessary because the queueTimestamp field was reset regularly on nodes that were in the cycle.
In the Node class, the new field and its getter and setter methods have been added. The field is set to the current timestamp in the constructor.
When a node at an existing IP address is updated, the identifier-change timestamp is updated. This is the only location where this field is updated outside of the Node constructor. So, unlike the queueTimestamp field, this field will not cause an identifier to be locked to an IP address indefinitely.


SYMBOL PROPERTY SYNTAX
GENERAL RULES
For symbols a global property string (to show it press 'q' when nothing is selected and Options->Symbol global attrs is selected) defines at least 3 attributes:
- type defines the the type of symbol. Normally the type attribute describes the symbol and ignored by XSCHEM, but there are some special types:
- subcircuit: the symbol has an underlining schematic representation, when producing the netlist XSCHEM has to descend into the corresponding schematic. This will be covered in the subcircuits chapter.
- primitive: the symbol has a schematic representation, you can descend into it but the netlister will not use it. This is very useful if you want to netlist a symbol using only the format (or vhdl_format or verilog_format depending on the netlist type) attribute or use the underlying schematic. By setting the attribute back to subcircuit and deleting (or setting to false) the verilog_format of vhdl_format attribute you can quickly change the behavior. For spice netlists the format attribute is always used also for subcircuits instantiation so always leave it there.
- Any value different from subcircuit or primitive will cause xschem to not use any schematic file even if it exists. Xschem will not allow to descend into an existing schematic.
- label: the symbol is used to label a net. These type of symbols must have one and only one pin, and the template string must define a lab attribute that is passed at component instantiationi to name the net it is attached to.
- probe: this denotes a probe symbol that may be backannotated with a backannotation script (example: ngspice_backannotate.tcl).
- ngprobe: This is a probe element that uses a 'pull' method to fetch simulation data and display it in current schematic. The data displayed is thus dynamic, multiple instancs of the same symbol with annotators will display operating point data for that particular instance without the need to update the backannotation as is required for annotators using the 'push' annotation methid.
- netlist_commands: the symbol is used to place SPICE commands into a spice netlist. It should also have a value attribute that may contain arbitrary text that is copied verbatim into the netlist. More on this in the netlist slide.
- format:The format attribute defines the syntax for the SPICE netlist. the @
character is a 'substitution character', it means that the token that follows is a parameter
that will be substituted with the value passed at component instantiation. If no
value is given there a value will be picked from the attribute declared in the template
string.
The @pinlist is a special token that will be substituted with the name of the wires that connect to symbol pins, in the order they are created in the symbol. See the pin ordering section in the xschem properties slide. if the order of pins for a NMOS symbol is for example, d,g,s,b, then @pinlist will be expanded when producing a netlist to the list of nets that connect to the symbol drain, gate, source, body respectively. There is also a special way to define single pins: @@d for example will be replaced by XSCHEM with the net that connects to the d pin of the symbol. so for example @pinlist is equivalent to @@d @@g @@s @@b. However using @pinlist and setting the correct pin ordering in the symbol pins will make netlist generation faster. This is important for very big components with lot of pins, and @pinlist is the default when symbol is generated automatically (Symbol ->Make symbol menu of <Shift>A key).
The format attribute may contain a @spiceprefix string immediately preceding (with no spaces) the @name attribute.. This will be substituted with value given in instance (example: spiceprefix=X) but *ONLY* if Simulation->Use 'spiceprefix' attribute is set. This allows to create different netlists for simulation (example: all MOS are defined as subcircuits) or LVS (no device subcircuits). - template: Specifies default values for symbol parameters
Only symbols of type subcircuit or primitive may be descended into with the 'e' bindkey if they have a schematic view.
The order these attributes appear in the property string is not important, they can be on the same line or on different lines:
type=nmos format="@name @pinlist @model w=@w l=@l m=@m" template="name=m1 model=nmos w=5u l=0.18u m=1"
format="@name @pinlist @model w=@w l=@l m=@m" template="name=m1 model=nmos w=5u l=0.18u m=1" type=nmos
As you see double quotes are used when attribute values have spaces. For this reason if double quotes are needed in an attribute value they must be escaped with backslash \"
since the symbol global property string is formatted as a space separated list of attribute=value items, if a value has spaces in it it must be enclosed in double quotes, see for example the symbol template attribute: template="name=m1 model=nmos w=5u l=0.18u m=1" or the the format attribute: format="@name @pinlist @model w=@w l=@l m=@m". As a direct consequence a literal double quote in property strings must be escaped (\")
ATTRIBUTE SUBSTITUTION
XSCHEM uses a method for attribute substitution that is very similar to shell variable expansion
done with the $ character (for example
$HOME --> /home/user) The only
difference is that XSCHEM uses the '@' character. The choice of '@' vs '$' is simply because
in some simulation netlists shell variables are passed to the simulator for expansion, so to avoid the
need to escape the '$' in property strings a different and less used character was chosen.
A literal @ must be escaped to prevent it to be interpreted as the start of a token to be
substituted (\@). If a non space character (different than @) ends a token it must be escaped.
Attribute substitution with values defined in instance attributes takes place in symbol
format attribute and in every text, as shown in below picture.
In recent xschem versions a $ prefixed attribute (example: $var) can be used
instead of a
If no matching attribute is defined in instance (for example we have @W in symbol and no W=... in instance) the @W string is substituted with an empty string.
OTHER PREDEFINED SYMBOL ATTRIBUTES
- vhdl_ignore
- spice_ignore
- verilog_ignore
- vhdl_stop
- spice_stop
- verilog_stop
- spice_primitive
- vhdl_primitive
- verilog_primitive
- highlight
- net_name
- place
- generic_type
These 3 attributes tell XSCHEM to ignore completely the symbol in the respective netlist formats.
These 3 attributes will avoid XSCHEM to descend into the schematic representation of the symbol (if there is one) when building the respective netlist format. For example, if an analog block has a schematic (.sch) file describing the circuit that is meaningless when doing a VHDL netlist, we can use a vhdl_stop=true attribute to avoid descending into the schematic. Only the global property of the schematic will be netlisted. This allows to insert some behavioral VHDL code in the global schematic property that describes the block in a way the VHDL simulator can understand.
same as above _stop attributes, but in this case the schematic subcircuit is completely ignored, only the 'format' string is dumped to netlist. No component/entity is generated in vhdl netlist, no module declaration in verilog, no .subckt in spice, no schematic global attributes are exported to netlist.
If set to true the symbol will be highlighted when one of the nets attached to its pins are highlighted.
If set to true the #n:net_name symbol attributes will display the net names attached to pin terminals. the n is a pin number or name.
this attribute is only useable in netlist_commands type symbols (netlist.sym, code.sym,...) if set to end it tells XSCHEM that the component instance of that symbol must be netlisted at the end, after all the other elements. This is sometimes needed for SPICE commands that must ge given at the end of the netlist. This will be explained more in detail in the netlisting slide.
generic_type defines the type of parameters passed to VHDL components. Consider the following MOS symbol definition; the model attribute is declared as string and it will be quoted in VHDL netlists.
the resulting netlist is shown here, note that without the generic_type attribute the irf5305 string would not be quoted.
entity test2 is end test2 ; architecture arch_test2 of test2 is signal d : std_logic ; signal s : std_logic ; signal g : std_logic ; begin x3 : pmos3 generic map ( model => "irf5305" ) port map ( d => d , g => g , s => s ); end arch_test2 ;
This property specifies that some parameters defined in the format string are to be considered as additional pins. This allows to realize inherited connections, a kind of hidden pins with connections passed as parameters. Example of a symbol definition for the following cmos gate:
the symbol property list defines 2 extra pins , VCCPIN and VSSPIN that can be assigned to at component instantiation. The extra property tells XSCHEM that these 2 parameters are connection pins and not parameters and thus must not be declared as parameters in the .subckt line in a spice netlist:
type=subcircuit vhdl_stop=true format="@name @pinlist @VCCPIN @VSSPIN @symname wn=@wn ln=@ln wp=@wp lp=@lp m=@m" template="name=x1 m=1 + wn=30u ln=2.4u wp=20u lp=2.4u + VCCPIN=VCC VSSPIN=VSS" extra="VCCPIN VSSPIN" generic_type="m=integer wn=real ln=real wp=real lp=real VCCPIN=string VSSPIN=string" verilog_stop=true
with these definitions the above schematic will be netlisted as:
**.subckt prova1 x2 G_y G_a G_b G_c VCC VSS lvnand3 wn=1.8u ln=0.18u wp=1u lp=0.18u m=1 **.ends * expanding symbol: customlogicLib/lvnand3 # of pins=4 .subckt lvnand3 y a b c VCCPIN VSSPIN wn=30u ln=2.4u wp=20u lp=2.4u *.opin y *.ipin a *.ipin b *.ipin c m1 net2 a VSSPIN VSSPIN nlv w=wn l=ln geomod=0 m=1 m2 y a VCCPIN VCCPIN plv w=wp l=lp geomod=0 m=1 dxm2 0 VCCPIN dnwell area='(wp + 57u)*(lp + 31u)' pj='2*(wp +57u)+2*(lp +31u)' m3 y b VCCPIN VCCPIN plv w=wp l=lp geomod=0 m=1 dxm3 0 VCCPIN dnwell area='(wp + 57u)*(lp + 31u)' pj='2*(wp +57u)+2*(lp +31u)' m6 y c net1 VSSPIN nlv w=wn l=ln geomod=0 m=1 m4 y c VCCPIN VCCPIN plv w=wp l=lp geomod=0 m=1 dxm4 0 VCCPIN dnwell area='(wp + 57u)*(lp + 31u)' pj='2*(wp +57u)+2*(lp +31u)' m5 net1 b net2 VSSPIN nlv w=wn l=ln geomod=0 m=1 .ends
Without the extra property in the cmos gate symbol the following incorrect netlist will be produced:
**.subckt prova1 x2 G_y G_a G_b G_c VCC VSS lvnand3 wn=1.8u ln=0.18u wp=1u lp=0.18u m=1 **** begin user architecture code **** end user architecture code **.ends * expanding symbol: customlogicLib/lvnand3 # of pins=4 .subckt lvnand3 y a b c wn=30u ln=2.4u wp=20u lp=2.4u VCCPIN=VCC VSSPIN=VSS *.opin y *.ipin a *.ipin b *.ipin c m1 net2 a VSSPIN VSSPIN nlv w=wn l=ln geomod=0 m=1 m2 y a VCCPIN VCCPIN plv w=wp l=lp geomod=0 m=1 dxm2 0 VCCPIN dnwell area='(wp + 57u)*(lp + 31u)' pj='2*(wp +57u)+2*(lp +31u)' m3 y b VCCPIN VCCPIN plv w=wp l=lp geomod=0 m=1 dxm3 0 VCCPIN dnwell area='(wp + 57u)*(lp + 31u)' pj='2*(wp +57u)+2*(lp +31u)' m6 y c net1 VSSPIN nlv w=wn l=ln geomod=0 m=1 m4 y c VCCPIN VCCPIN plv w=wp l=lp geomod=0 m=1 dxm4 0 VCCPIN dnwell area='(wp + 57u)*(lp + 31u)' pj='2*(wp +57u)+2*(lp +31u)' m5 net1 b net2 VSSPIN nlv w=wn l=ln geomod=0 m=1 **** begin user architecture code **** end user architecture code .ends
as you can see the VSSPIN and VCCPIN are listed as parameters and not as pins in the netlist.
Defines the direction of a symbol pin. Allowed values are in, out, inout.
This attribute instructs xschem to do a 'propagate highlight' from the pin with this attribute to the pin n. The number 'n' refers to the pin sequence number (do a shift-S after selecting destination pin to know this information).
This attribute is used in the xschem embedded digital simulation engine: propagate logic simulation to the output pins n,[m,...]. The logic function is defined via the 'functionn' global attribute. There is one 'funtionn' for each n output pin. see 'functionn' attribute for more info.
A clock attribute defined on input pins add some information on the pin function as follows:
- clock=0 This indicates an 'active low' clock signal for flip-flops
- clock=1 This indicates an 'active high' clock signal for flip-flops
- clock=2 This indicates an 'active low' reset signal for flip-flops
- clock=3 This indicates an 'active high' reset signal for flip-flops
This attribute is set in the symbol global attributes and specifies the logic function to be applied to the associated output pin. The format is: function<n>="...logic function..." where the number <n> refers to the sequence number of the output pin (do a 'Shift-S' after selecting the pin to know its sequence number). Multiple functions (function3="...", function4="...") can be defined in case of elements with multiple outputs.
Commands that can appear in functions are:
- n: A digit indicates to put on the stack the logic value (0, 1, X) of pin with sequence number n The sequence number of a pin my be obtained by clicking the red square of the pin and pressing Shift-S.
- &: Does a logical AND operation of the last 2 elements on top of the stack, the result is left on the stack
- |: Does a logical OR operation of the last 2 elements on top of the stack, the result is left on the stack
- ^: Does a logical XOR operation of the last 2 elements on top of the stack, the result is left on the stack
- ~: Does a logical Negation operation of the last element on top of the stack, the result is left on the stack
- d: Duplicates top element on the stack
- x: Exhanges the 2 top elements on the stack
- H: Puts a Logic '1' on the stack
- L: Puts a Logic '0' on the stack
The remaining value on the stack is the value that is returned and assigned to the output pin.
a global=true property in a label type symbol will declare the corresponding net as 'global'. Global nets in spice netlists are like global variables in a C program, these nets are accessible at any hierarchical level without the need of passing them through pin connections.
If any of these 3 properties if set to true the symbol will be netlisted in the specified format. This is only valid if the split file netlisting mode is active (Options -> Split netlist). This is very rarely used but is required in mixed mode simulations, where part of the system will be handled by an analog simulator (spice) and another part of the system by a digital Verilog / VHDL simulator.
This is the Verilog equivalent of the format property for Spice primitives. This is a valid definition for a 2 input inverted XOR gate:
verilog_format="xnor #(@risedel , @falldel ) @name ( @@Z , @@A , @@B );"
same as above for VHDL primitives.
same as above for tEDAx netlists.
This attribute contains a SPICE .model or .subckt specification (device_model=".model D1N4148 D ....") that will be printed at end of netlist only once for the specified component (D1N4148 in the example).
PREDEFINED SYMBOL VALUES
- @symname
- @pinlist
- @@pin
- @#n
- @#n:pin_attribute
- @#pin_name:pin_attribute
- @#pin_name:net_name
- @#n:net_name
- @sch_last_modified
- @sym_last_modified
- @time_last_modified
- @schname
- @prop_ptr
- @schprop
- @schvhdlprop
- @schverilogprop
This expands to the name of the symbol
This expands to the list of nets that connect to symbol pins in the order they are set in the symbol
This expands to the net that connect to symbol pin named pin. This substitution takes place only when producing a netlist (Spice, Verilog, VHDL, tEDAx) so it is allowed to use this value only in format,vhdl_format, tedax_format or verilog_format attributes (see Netlisting slide)
This expands to the net that connect to symbol pin at position n in the XSCHEM internal storage. This substitution
takes place only when producing a netlist (Spice, Verilog, VHDL, tEDAx) so it is allowed to use this
value only in format,vhdl_format, tedax_format or verilog_format
attributes (see Netlisting slide)
This method of accessing a net that connects to a pin is much faster than previous one since XSCHEM does not need to
loop through symbol pin names looking for a match.
Example: @#2: return net name that connects to the third pin of the symbol (position 2).
This expands to the value or property pin_attribute defined in the pin at position n
in the XSCHEM internal storage. This method of looking up properties is very fast.
Example: @#0:pinnumber: This expands to the value of the pinnumber defined in pin object at position 0 in the xschem
internal ordering. This format is very useful for slotted devices where the actual displayed pin number depends on the slot
information defined in the instance name (example: U1:2, slot number 2 of IC U1).
These tokens may be placed as text in the symbol graphic window, not in format strings.
This expands to the value or property pin_attribute defined in the pin named pin_name
This method of looking up properties is a bit slower since xschem has to do string matching to find out the pin.
Example: @#A:pinnumber: This expands to the value of the pinnumber defined in pin A.
This format is very useful for slotted devices where the actual displayed pin number depends on the slot
information defined in the instance name (example: U1:2, slot number 2 of IC U1).
These tokens may be placed as text in the symbol graphic window, not in format strings.
these expand to the net name attached to pin with name pin_name or with sequence number n.
this indicates the last modification time of the .sch file of the symbol.
this indicates the last modification time of the .sym file of the symbol.
this indicates the last modification time of the schematic (.sch) containing the symbol instance.
this expands to the name of the schematic (.sch) containing the symbol instance.
this expandes to the entire property string passed to the component.
this expandes to the spice global property string of the schematic containing the symbol
this expandes to the VHDL global property string of the schematic containing the symbol
this expandes to the Verilog global property string of the schematic containing the symbol


Education
-
Old Dominion University
August 2019 - December 2020
Master of Computer Science
August 2015 - May 2019
Bachelor of Computer Science
Skills
-
Computer Skills
C++, Java, Python, R, HTML, CSS, PHP, MySQL, Microsoft Office, Adobe Creative Cloud
-
Personal Skills
Problem-Solving, Critical Thinking, Teamwork, Time Management, Interpersonal Communication
Work Experience
-
Graduate Teaching Assistant, Old Dominion University
August 2019 - December 2020
Instructed recitations for CS120/121 Information Literacy and Research. Created instructional PowerPoints and new assignments.
-
Global Product and Technology Intern, ADP, Norfolk, Virginia
June 2020 - August 2020
Improved a web application by adding a search bar. Assigned access and created new integrations for the web application.
-
Graduate Research Assistant, Old Dominion University Research Foundation, Norfolk, Virginia
August 2019 - May 2020
Conducted research on Finite Element Mesh Generation. Presented 2 posters titled "“Image-to-Mesh Conversion Tool (I2MTool) for Image-Driven Simulations" at VSGC's Research Conference and ODU’s Undergraduate Research Symposium.
-
NASA Intern, NASA Langley, Hampton Virginia
January 2018 - June 2018
Worked on projects to gain an educational experience in Computer Science and Aerodynamics. Attended lectures, tours, and workshops to enhance my skills and knowledge.
-
Web Developer
Aug 2016 - Present
STEAMtrix, LLC, Kids Gotta Eat Trucking Company , and STEAMkitx, LLC
-
Desk Receptionist, ODU Housing and Residence Life
Aug 2016 - May 2018
Demonstrated strong leadership abilities and great time management skills. Exemplified great organization and team work skills.
Research Experience
-
Center for Real-Time Computing Lab, Old Dominion University
August 2017 - August 2020
Curated and maintained the CRTC Lab wiki to display current research and information regarding Parallel FE Mesh Generation, Real-Time Medical Image computing, Parallel Software Runtime Systems, and STEM education. Conducted research on Finite Element Mesh Generation.
-
Conference Presentations
April 2019
“Image-to-Mesh Conversion Tool (I2MTool) for Image-Driven Simulations”, Virginia Space Grant Consortium’s Student Research Conference
February 2019
“Image-to-Mesh Conversion Tool (I2MTool) for Image-Driven Simulations”, Old Dominion University’s Undergraduate Research Symposium
Honors and Awards
-
Dr. Hussein Abdel-Wahab Memorial Graduate Fellowship
Fall 2019, Awarded to one graduate student seeking a Graduate degree in Computer Science
-
Certificate of Excellence in Undergraduate Research
Spring 2019, Awarded to students who presented work at the ODU Undergraduate Research Symposium
-
VSGC Undergraduate Research Scholarship
Summer 2018, Awarded to underrepresented minorities in STEM demonstrating an interest in research
-
STEM Bridge Scholarship
Fall 2016 & 2017, Awarded to underrepresented minorities demonstrating interest in STEM related fields
The Karlem Riess Scholarship
Fall 2018, Awarded to Phi Eta Sigma members who have made an impact in the community


The Available Courses page displays all of the courses in the Learning Center. To view the page, open the Algorithm Lab and then, in the left navigation bar, click
.Each course displays the following information:
Click a course to learn more about it, including the following:


Invalid username and password.
You have been logged out.
Please Login
Username
Password
Login
© 2019 Avalah
Usernames: avalah, egonraamat, jooseptruu
Password for all: avalah


https://linux.die.net/man/1/scp
gtfo bins only has the -S option, but there is an -o ProxyCommand option as well
https://cxsecurity.com/issue/WLB-2014060133
https://seclists.org/fulldisclosure/2014/Jun/121
$ scp * user () example org:/var/www/
To exploit this command, in the directory we place these files.
- - "-o" - SCP will interpret this file as the "-o" switch.
- - "ProxyCommand sh supercool.sh %h %p" - SCP will interpret this file's
name as the argument to the "-o" switch.
- - "supercool.sh" - The script that will run, containing the attacker's
code.
- - "zzz.txt" - Another file in the directory which serves no purpose for
the exploit.
Inside "supercool.sh", we have a script that will do what "ProxyCommand"
is supposed to do, along with some malicious commands.
When the victim runs their scp command, it will appear successful:
$ scp * user () example org:/var/www/
supercool.sh
zzz.txt
But really, supercool.sh has executed, and we now have control of the
user's system.